Timepicker triggers dirty flag inside ngRepeat

[bsweeney]

Using just Angular 1.3.3 and Angular-UI 0.12.0, when the following code loads:

JS:

$scope.groups = [];
$scope.groups.push(
  {when: new Date(2014,9,1,10,15)}
);

HTML:

<div>
  <div ng-repeat="group in groups">
    <timepicker ng-model="group.when"></timepicker>
  </div>
</div>

The timepicker element is immediately marked dirty/triggers the change event. This is problematic when attempting to check for changes on page unload as there will always be detected changes. See here:
http://plnkr.co/Ic2HA390OI2xheT38Izz

This does not happen outside ngRepeat, or with a simple text input inside the ngRepeat. See here:
http://plnkr.co/s0KwGrZkHaog4efyjGBK

I have managed to work around the issue by modifying the directive, but I'm not sure that my change is safe. The modification is to the refresh() function:

  function refresh( keyboardChange ) {
    makeValid();
    if (ngModelCtrl.$viewValue.getTime() != new Date(selected).getTime()) {
      ngModelCtrl.$setViewValue(new Date(selected));
    }
    updateTemplate( keyboardChange );
  }

[bsweeney]

My change was not entirely safe. If the timepicker was invalidated (by, say, deleting one of the component values) then it would continuously fail to validate afterwards. I tweaked the modification slightly.

  function refresh( keyboardChange ) {
    makeValid();
    if (!ngModelCtrl.$viewValue || ngModelCtrl.$viewValue.getTime() != new Date(selected).getTime()) {
      ngModelCtrl.$setViewValue(new Date(selected));
    }
    updateTemplate( keyboardChange );
  }

(probably still not safe)

[wesleycho]

This is not quite right.

From some experimentation, it appears that what is causing the form to be set as dirty is the refresh function being called twice, once for having a valid hours value and once for having a valid minutes value.

The correct fix then should be to check if each function is called for the first time on load, set the form to pristine, then toggle an internal variable so that the form cannot be set to pristine again via these mechanisms.

[chrisirhc]

Added a comment to the PR, it's due to the new handling of type="text" (vs `type="number").