"Fossies" - the Fresh Open Source Software Archive

Member "angular.js-1.7.9/CHANGELOG.md" (19 Nov 2019, 956565 Bytes) of package /linux/www/angular.js-1.7.9.tar.gz:


As a special service "Fossies" has tried to format the requested source page into HTML format (assuming markdown format). Alternatively you can here view or download the uninterpreted source code file. A member file download can also be achieved by clicking within a package contents listing on the according byte size field. See also the latest Fossies "Diffs" side-by-side code changes report for "CHANGELOG.md": 1.7.8_vs_1.7.9.

# 1.7.9 pollution-eradication (2019-11-19)

Bug Fixes

# 1.7.8 enthusiastic-oblation (2019-03-11)

Bug Fixes

# 1.7.7 kingly-exiting (2019-02-04)

Bug Fixes

# 1.7.6 gravity-manipulation (2019-01-17)

Bug Fixes

Performance Improvements

# 1.7.5 anti-prettification (2018-10-04)

Bug Fixes

# 1.7.4 interstellar-exploration (2018-09-07)

Bug Fixes

# 1.7.3 eventful-proposal (2018-08-03)

Bug Fixes

New Features

Performance Improvements

# 1.7.2 extreme-compatiplication (2018-06-12)

In the previous release, we removed a private, undocumented API that was no longer used by AngularJS. It turned out that several popular UI libraries (such as AngularJS Material, UI Bootstrap, ngDialog and probably others) relied on that API.

In order to avoid unnecessary pain for developers, this release reverts the removal of the private API and restores compatibility of the aforementioned libraries with the latest AngularJS.

Reverts

# 1.7.1 momentum-defiance (2018-06-08)

Bug Fixes

New Features

# 1.7.0 nonexistent-physiology (2018-05-11)

Here are the full changes for the release of 1.7.0 that are not already released in the 1.6.x branch, which includes commits from 1.7.0-rc.0 and commits from 1.7.0 directly.

1.7.0 is the last scheduled release of AngularJS that includes breaking changes. 1.7.x patch releases will continue to receive bug fixes and non-breaking features until AngularJS enters Long Term Support mode (LTS) on July 1st 2018.

Bug Fixes

New Features

Performance Improvements

Breaking Changes

jqLite due to:

Before this commit removeData() invoked on an element removed its event handlers as well. If you want to trigger a full cleanup of an element, change:

elem.removeData();

to:

angular.element.cleanData(elem);

In most cases, though, cleaning up after an element is supposed to be done only when it’s removed from the DOM as well; in such cases the following:

elem.remove();

will remove event handlers as well.

$cookies due to:

The $cookieStore has been removed. Migrate to the $cookies service. Note that for object values you need to use the putObject & getObject methods as get/put will not correctly save/retrieve them.

Before:

$cookieStore.put('name', {key: 'value'});
$cookieStore.get('name'); // {key: 'value'}
$cookieStore.remove('name');

After:

$cookies.putObject('name', {key: 'value'});
$cookies.getObject('name'); // {key: 'value'}
$cookies.remove('name');

$resource due to:

If you are not using success or error callbacks with $resource, your app should not be affected by this change.

If you are using success or error callbacks (with or without response interceptors), one (subtle) difference is that throwing an error inside the callbacks will not propagate to the returned $promise. Therefore, you should try to use the promises whenever possible. E.g.:

// Avoid
User.query(function onSuccess(users) { throw new Error(); }).
  $promise.
  catch(function onError() { /* Will not be called. */ });

// Prefer
User.query().
  $promise.
  then(function onSuccess(users) { throw new Error(); }).
  catch(function onError() { /* Will be called. */ });

Finally, if you are using success or error callbacks with response interceptors, the callbacks will now always run after the interceptors (and wait for them to resolve in case they return a promise). Previously, the error callback was called before the responseError interceptor and the success callback was synchronously called after the response interceptor. E.g.:

var User = $resource('/api/users/:id', {id: '@id'}, {
  get: {
    method: 'get',
    interceptor: {
      response: function(response) {
        console.log('responseInterceptor-1');
        return $timeout(1000).then(function() {
          console.log('responseInterceptor-2');
          return response.resource;
        });
      },
      responseError: function(response) {
        console.log('responseErrorInterceptor-1');
        return $timeout(1000).then(function() {
          console.log('responseErrorInterceptor-2');
          return $q.reject('Ooops!');
        });
      }
    }
  }
});
var onSuccess = function(value) { console.log('successCallback', value); };
var onError = function(error) { console.log('errorCallback', error); };

// Assuming the following call is successful...
User.get({id: 1}, onSuccess, onError);
  // Old behavior:
  //   responseInterceptor-1
  //   successCallback, {/* Promise object */}
  //   responseInterceptor-2
  // New behavior:
  //   responseInterceptor-1
  //   responseInterceptor-2
  //   successCallback, {/* User object */}

// Assuming the following call returns an error...
User.get({id: 2}, onSuccess, onError);
  // Old behavior:
  //   errorCallback, {/* Response object */}
  //   responseErrorInterceptor-1
  //   responseErrorInterceptor-2
  // New behavior:
  //   responseErrorInterceptor-1
  //   responseErrorInterceptor-2
  //   errorCallback, Ooops!

Previously, calling a $resource method would synchronously call $http. Now, it will be called asynchronously (regardless if a request/requestError interceptor has been defined.

This is not expected to affect applications at runtime, since the overall operation is asynchronous already, but may affect assertions in tests. For example, if you want to assert that $http has been called with specific arguments as a result of a $resource call, you now need to run a $digest first, to ensure the (possibly empty) request interceptor promise has been resolved.

Before:

it('...', function() {
  $httpBackend.expectGET('/api/things').respond(...);
  var Things = $resource('/api/things');
  Things.query();

  expect($http).toHaveBeenCalledWith(...);
});

After:

it('...', function() {
  $httpBackend.expectGET('/api/things').respond(...);
  var Things = $resource('/api/things');
  Things.query();
  $rootScope.$digest();

  expect($http).toHaveBeenCalledWith(...);
});

$templateRequest:

Previously the tpload error was namespaced to $compile. If you have code that matches errors of the form [$compile:tpload] it will no longer run. You should change the code to match [$templateRequest:tpload].

The service now returns the result of $templateCache.put() when making a server request to the template. Previously it would return the content of the response directly. This now means if you are decorating $templateCache.put() to manipulate the template, you will now get this manipulated result also on the first $templateRequest rather than only on subsequent calls (when the template is retrived from the cache). In practice this should not affect any apps, as it is unlikely that they rely on the template being different in the first and subsequent calls.

$animate due to:

$animate.cancel(runner) now rejects the underlying promise and calls the catch() handler on the runner returned by $animate functions (enter, leave, move, addClass, removeClass, setClass, animate). Previously it would resolve the promise as if the animation had ended successfully.

Example:

var runner = $animate.addClass('red');
runner.then(function() { console.log('success')});
runner.catch(function() { console.log('cancelled')});

runner.cancel();

Pre-1.7.0, this logs ‘success’, 1.7.0 and later it logs ‘cancelled’. To migrate, add a catch() handler to your animation runners.

angular.isArray due to:

Previously, angular.isArray() was an alias for Array.isArray(). Therefore, objects that prototypally inherit from Array where not considered arrays. Now such objects are considered arrays too.

This change affects several other methods that use angular.isArray() under the hood, such as angular.copy(), angular.equals(), angular.forEach(), and angular.merge().

This in turn affects how dirty checking treats objects that prototypally inherit from Array (e.g. MobX observable arrays). AngularJS will now be able to handle these objects better when copying or watching.

**$sce** : - due to **[1e9ead](https://github.com/angular/angular.js/commit/1e9eadcd72dbbd5c67dae8328a63e535cfa91ff9)**: handle URL sanitization through the `$sce` service

If you use attrs.$set for URL attributes (a[href] and img[src]) there will no longer be any automated sanitization of the value. This is in line with other programmatic operations, such as writing to the innerHTML of an element.

If you are programmatically writing URL values to attributes from untrusted input then you must sanitize it yourself. You could write your own sanitizer or copy the private $$sanitizeUri service.

Note that values that have been passed through the $interpolate service within the URL or MEDIA_URL will have already been sanitized, so you would not need to sanitize these values again.

binding trustAs() and the short versions (trustAsResourceUrl() et al.) to ngSrc, ngSrcset, and ngHref will now raise an infinite digest error:

  $scope.imgThumbFn = function(id) {
    return $sce.trustAsResourceUrl(someService.someUrl(id));
  };
  <img ng-src="{{imgThumbFn(imgId)}}">

This is because the $interpolate service is now responsible for sanitizing the attribute value, and its watcher receives a new object from trustAs() on every digest. To migrate, compute the trusted value only when the input value changes:

  $scope.$watch('imgId', function(id) {
    $scope.imgThumb = $sce.trustAsResourceUrl(someService.someUrl(id));
  });
  <img ng-src="{{imgThumb}}">

orderBy due to:

When using orderBy to sort arrays containing null values, the null values will be considered “greater than” all other values, except for undefined. Previously, they were sorted as strings. This will result in different (but more intuitive) sorting order.

Before:

orderByFilter(['a', undefined, 'o', null, 'z']);
//--> 'a', null, 'o', 'z', undefined

After:

orderByFilter(['a', undefined, 'o', null, 'z']);
//--> 'a', 'o', 'z', null, undefined

ngScenario due to:

The angular scenario runner end-to-end test framework has been removed from the project and will no longer be available on npm or bower starting with 1.7.0. It was deprecated and removed from the documentation in 2014. Applications that still use it should migrate to Protractor. Technically, it should also be possible to continue using an older version of the scenario runner, as the underlying APIs have not changed. However, we do not guarantee future compatibility.

form due to:

Forms will now set $submitted on child forms when they are submitted. For example: ``` <form name="parentform" ng-submit="$ctrl.submit()">

Submitting this form will set $submitted on "parentform" and "childform".
Previously, it was only set on "parentform".

This change was introduced because mixing form and ngForm does not create
logically separate forms, but rather something like input groups.
Therefore, child forms should inherit the submission state from their parent form.

### **ngAria** due to:
  - **[6d5ef3](https://github.com/angular/angular.js/commit/6d5ef34fc6a974cde73157ba94f9706723dd8f5b)**: do not set aria attributes on input[type="hidden"]

ngAria no longer sets aria-* attributes on input[type="hidden"] with ngModel.
This can affect apps that test for the presence of aria attributes on hidden inputs.
To migrate, remove these assertions.
In actual apps, this should not have a user-facing effect, as the previous behavior
was incorrect, and the new behavior is correct for accessibility.

### **ngModel, input** due to:
  - **[74b04c](https://github.com/angular/angular.js/commit/74b04c9403af4fc7df5b6420f22c9f45a3e84140)**: improve handling of built-in named parsers

*Custom* parsers that fail to parse on input types "email", "url", "number", "date", "month",
"time", "datetime-local", "week", do no longer set `ngModelController.$error[inputType]`, and
the `ng-invalid-[inputType]` class. Also, custom parsers on input type "range" do no
longer set `ngModelController.$error.number` and the `ng-invalid-number` class.

Instead, any custom parsers on these inputs set `ngModelController.$error.parse` and
`ng-invalid-parse`. This change was made to make distinguishing errors from built-in parsers
and custom parsers easier.

### **ngModelOptions** due to:
  - **[55ba44](https://github.com/angular/angular.js/commit/55ba44913e02650b56410aa9ab5eeea5d3492b68)**: add debounce catch-all + allow debouncing 'default' only

the 'default' key in 'debounce' now only debounces the default event, i.e. the event
that is added as an update trigger by the different input directives automatically.

Previously, it also applied to other update triggers defined in 'updateOn' that
did not have a corresponding key in the 'debounce'.

This behavior is now supported via a special wildcard / catch-all key: '*'.

See the following example:

Pre-1.7:
'mouseup' is also debounced by 500 milliseconds because 'default' is applied:

ng-model-options="{ updateOn: ‘default blur mouseup’, debounce: { ‘default’: 500, ‘blur’: 0 } }


1.7:
The pre-1.7 behavior can be re-created by setting '*' as a catch-all debounce value:

ng-model-options="{ updateOn: ‘default blur mouseup’, debounce: { ’*‘: 500, ’blur’: 0 } }


In contrast, when only 'default' is used, 'blur' and 'mouseup' are not debounced:

ng-model-options="{ updateOn: ‘default blur mouseup’, debounce: { ‘default’: 500 } }


### **input\[number\]** due to:
  - **[aa3f95](https://github.com/angular/angular.js/commit/aa3f951330ec7b10b43ea884d9b5754e296770ec)**: validate min/max against viewValue

`input[type=number]` with `ngModel` now validates the input for the `max`/`min` restriction against
the `ngModelController.$viewValue` instead of against the `ngModelController.$modelValue`.

This affects apps that use `$parsers` or `$formatters` to transform the input / model value.

If you rely on the $modelValue validation, you can overwrite the `min`/`max` validator from a custom directive, as seen in the following example directive definition object:

{ restrict: ‘A’, require: ‘ngModel’, link: function(scope, element, attrs, ctrl) { var maxValidator = ctrl.$validators.max;

ctrl.$validators.max = function(modelValue, viewValue) {
  return maxValidator(modelValue, modelValue);
};

} }


### **input** due to:
  - **[656c8f](https://github.com/angular/angular.js/commit/656c8fa8f23b1277cc5c214c4d0237f3393afa1e)**: listen on "change" instead of "click" for radio/checkbox ngModels

`input[radio]` and `input[checkbox]` now listen to the "change" event instead of the "click" event.
Most apps should not be affected, as "change" is automatically fired by browsers after "click"
happens.

Two scenarios might need migration:

- Custom click events:

Before this change, custom click event listeners on radio / checkbox would be called after the
input element and `ngModel` had been updated, unless they were specifically registered before
the built-in click handlers.
After this change, they are called before the input is updated, and can call event.preventDefault()
to prevent the input from updating.

If an app uses a click event listener that expects ngModel to be updated when it is called, it now
needs to register a change event listener instead.

- Triggering click events:

Conventional trigger functions:

The change event might not be fired when the input element is not attached to the document. This
can happen in **tests** that compile input elements and
trigger click events on them. Depending on the browser (Chrome and Safari) and the trigger method,
the change event will not be fired when the input isn't attached to the document.

Before:

```js
    it('should update the model', inject(function($compile, $rootScope) {
      var inputElm = $compile('<input type="checkbox" ng-model="checkbox" />')($rootScope);

      inputElm[0].click(); // Or different trigger mechanisms, such as jQuery.trigger()
      expect($rootScope.checkbox).toBe(true);
    });

With this patch, $rootScope.checkbox might not be true, because the click event hasn’t triggered the change event. To make the test, work append the inputElm to the app’s $rootElement, and the $rootElement to the $document.

After:

    it('should update the model', inject(function($compile, $rootScope, $rootElement, $document) {
      var inputElm = $compile('<input type="checkbox" ng-model="checkbox" />')($rootScope);

      $rootElement.append(inputElm);
      $document.append($rootElement);

      inputElm[0].click(); // Or different trigger mechanisms, such as jQuery.trigger()
      expect($rootScope.checkbox).toBe(true);
    });

triggerHandler():

If you are using this jQuery / jqLite function on the input elements, you don’t have to attach the elements to the document, but instead change the triggered event to “change”. This is because triggerHandler(event) only triggers the exact event when it has been added by jQuery / jqLite.

ngStyle due to:

Previously the use of deep watch by ng-style would trigger styles to be re-applied when nested state changed. Now only changes to direct properties of the watched object will trigger changes.

$compile due to:

Previously, the $compileProvider.preAssignBindingsEnabled flag was supported. The flag controlled whether bindings were available inside the controller constructor or only in the $onInit hook. The bindings are now no longer available in the constructor.

To migrate your code:

  1. If you haven’t invoked $compileProvider.preAssignBindingsEnabled() you don’t have to do anything to migrate.

  2. If you specified $compileProvider.preAssignBindingsEnabled(false), you can remove that statement - since AngularJS 1.6.0 this is the default so your app should still work even in AngularJS 1.6 after such removal. Afterwards, migrating to AngularJS 1.7.0 shouldn’t require any further action.

  3. If you specified $compileProvider.preAssignBindingsEnabled(true) you need to first migrate your code so that the flag can be flipped to false. The instructions on how to do that are available in the “Migrating from 1.5 to 1.6” guide: https://docs.angularjs.org/guide/migration#migrating-from-1-5-to-1-6 Afterwards, remove the $compileProvider.preAssignBindingsEnabled(true) statement.

In the unlikely case that an app relied on RESOURCE_URL whitelisting for the purpose of binding to the xlink:href property of SVG’s <a> or <image> elements and if the values do not pass the regular URL sanitization, they will break.

To fix this you need to ensure that the values used for binding to the affected xlink:href contexts are considered safe URLs, e.g. by whitelisting them in $compileProvider’s aHrefSanitizationWhitelist (for <a> elements) or imgSrcSanitizationWhitelist (for <image> elements).

Previously when a literal value was passed into a directive/component via one-way binding it would be watched with a deep watcher.

For example, for <my-component input="[a]">, a new instance of the array would be passed into the directive/component (and trigger $onChanges) not only if a changed but also if any sub property of a changed such as a.b or a.b.c.d.e etc.

This also means a new but equal value for a would NOT trigger such a change.

Now literal values use an input-based watch similar to other directive/component one-way bindings. In this context inputs are the non-constant parts of the literal. In the example above the input would be a. Changes are only triggered when the inputs to the literal change.

Previously, <base href="{{ $ctrl.baseUrl }}" /> would not require baseUrl to be trusted as a RESOURCE_URL. Now, baseUrl will be sent to $sce’s RESOURCE_URL checks. By default, it will break unless baseUrl is of the same origin as the application document.

Refer to the $sce API docs for more info on how to trust a value in a RESOURCE_URL context.

Also, concatenation in trusted contexts is not allowed, which means that the following won’t work: <base href="/something/{{ $ctrl.partialPath }}" />.

Either construct complex values in a controller (recommended):

this.baseUrl = '/something/' + this.partialPath;
<base href="{{ $ctrl.baseUrl }}" />

Or use string concatenation in the interpolation expression (not recommended except for the simplest of cases):

<base href="{{ '/something/' + $ctrl.partialPath }}" />

ngTouch due to:

The ngClick directive from the ngTouch module has been removed, and with it the corresponding $touchProvider and $touch service.

If you have included ngTouch v1.5.0 or higher in your application, and have not changed the value of $touchProvider.ngClickOverrideEnabled(), or injected and used the $touch service, then there are no migration steps for your code. Otherwise you must remove references to the provider and service.

The ngClick override directive had been deprecated and by default disabled since v1.5.0, because of buggy behavior in edge cases, and a general trend to avoid special touch based overrides of click events. In modern browsers, it should not be necessary to use a touch override library:

You can find out more in these articles: https://developers.google.com/web/updates/2013/12/300ms-tap-delay-gone-away https://developer.apple.com/library/content/releasenotes/General/WhatsNewInSafari/Articles/Safari_9_1.html#//apple_ref/doc/uid/TP40014305-CH10-SW8 https://blogs.msdn.microsoft.com/ie/2015/02/24/pointer-events-w3c-recommendation-interoperable-touch-and-removing-the-dreaded-300ms-tap-delay/

Angular due to:

The helper functions angular.lowercase and angular.uppercase have been removed.

These functions have been deprecated since 1.5.0. They are internally used, but should not be exposed as they contain special locale handling (for Turkish) to maintain internal consistency regardless of user-set locale.

Developers should generally use the built-ins toLowerCase and toUpperCase or toLocaleLowerCase and toLocaleUpperCase for special cases.

Further, we generally discourage using the angular.x helpers in application code.

$controller due to:

The option to instantiate controllers from constructors on the global window object has been removed. Likewise, the deprecated $controllerProvider.allowGlobals() method that could enable this behavior, has been removed.

This behavior had been deprecated since AngularJS v1.3.0, because polluting the global scope is bad. To migrate, remove the call to $controllerProvider.allowGlobals() in the config, and register your controller via the Module API or the $controllerProvider, e.g.

angular.module('myModule', []).controller('myController', function() {...});

angular.module('myModule', []).config(function($controllerProvider) {
  $controllerProvider.register('myController', function() {...});
});

$rootScope due to:

Previously when using $watchGroup the entries in newValues and oldValues represented the most recent change of each entry.

Now the entries in oldValues will always equal the newValues of the previous call of the listener. This means comparing the entries in newValues and oldValues can be used to determine which individual expressions changed.

For example $scope.$watchGroup(['a', 'b'], fn) would previously:

Action newValue oldValue
(init) [undefined, undefined] [undefined, undefined]
a=1 [1, undefined] [undefined, undefined]
a=2 [2, undefined] [1, undefined]
b=3 [2, 3] [1, undefined]

Now the oldValue will always equal the previous newValue:

Action newValue oldValue
(init) [undefined, undefined] [undefined, undefined]
a=1 [1, undefined] [undefined, undefined]
a=2 [2, undefined] [1, undefined]
b=3 [2, 3] [2, undefined]

Note the last call now shows a === 2 in the oldValues array.

This also makes the oldValue of one-time watchers more clear. Previously the oldValue of a one-time watcher would remain undefined forever. For example $scope.$watchGroup(['a', '::b'], fn) would previously:

Action newValue oldValue
(init) [undefined, undefined] [undefined, undefined]
a=1 [1, undefined] [undefined, undefined]
b=2 [1, 2] [undefined, undefined]
a=b=3 [3, 2] [1, undefined]

Where now the oldValue will always equal the previous newValue:

Action newValue oldValue
(init) [undefined, undefined] [undefined, undefined]
a=1 [1, undefined] [undefined, undefined]
b=2 [1, 2] [1, undefined]
a=b=3 [3, 2] [1, 2]

**interval *  * dueto :  −  *  * [a8bef9](https : //github.com/angular/angular.js/commit/a8bef95127775d83d80daa4617c33227c4b443d4) *  *  : throwwhentryingtocancelnoninterval promise

$interval.cancel() will throw an error if called with a promise that was not generated by $interval(). Previously, it would silently do nothing.

Before:

var promise = $interval(doSomething, 1000, 5).then(doSomethingElse);
$interval.cancel(promise);  // No error; interval NOT canceled.

After:

var promise = $interval(doSomething, 1000, 5).then(doSomethingElse);
$interval.cancel(promise);  // Throws error.

Correct usage:

var promise = $interval(doSomething, 1000, 5);
var newPromise = promise.then(doSomethingElse);
$interval.cancel(promise);  // Interval canceled.

**timeout *  * dueto :  −  *  * [336525](https : //github.com/angular/angular.js/commit/3365256502344970f86355d3ace1cb4251ae9828) *  *  : throwwhentryingtocancelnontimeout promise

$timeout.cancel() will throw an error if called with a promise that was not generated by $timeout(). Previously, it would silently do nothing.

Before:

var promise = $timeout(doSomething, 1000).then(doSomethingElse);
$timeout.cancel(promise);  // No error; timeout NOT canceled.

After:

var promise = $timeout(doSomething, 1000).then(doSomethingElse);
$timeout.cancel(promise);  // Throws error.

Correct usage:

var promise = $timeout(doSomething, 1000);
var newPromise = promise.then(doSomethingElse);
$timeout.cancel(promise);  // Timeout canceled.

# 1.7.0-rc.0 maximum-overdrive (2018-04-19)

Bug Fixes

New Features

Performance Improvements

Breaking Changes

jqLite due to:

Before this commit removeData() invoked on an element removed its event handlers as well. If you want to trigger a full cleanup of an element, change:

elem.removeData();

to:

angular.element.cleanData(elem);

In most cases, though, cleaning up after an element is supposed to be done only when it’s removed from the DOM as well; in such cases the following:

elem.remove();

will remove event handlers as well.

$cookies due to:

The $cookieStore has been removed. Migrate to the $cookies service. Note that for object values you need to use the putObject & getObject methods as get/put will not correctly save/retrieve them.

Before:

$cookieStore.put('name', {key: 'value'});
$cookieStore.get('name'); // {key: 'value'}
$cookieStore.remove('name');

After:

$cookies.putObject('name', {key: 'value'});
$cookies.getObject('name'); // {key: 'value'}
$cookies.remove('name');

$resource due to:

If you are not using success or error callbacks with $resource, your app should not be affected by this change.

If you are using success or error callbacks (with or without response interceptors), one (subtle) difference is that throwing an error inside the callbacks will not propagate to the returned $promise. Therefore, you should try to use the promises whenever possible. E.g.:

// Avoid
User.query(function onSuccess(users) { throw new Error(); }).
  $promise.
  catch(function onError() { /* Will not be called. */ });

// Prefer
User.query().
  $promise.
  then(function onSuccess(users) { throw new Error(); }).
  catch(function onError() { /* Will be called. */ });

Finally, if you are using success or error callbacks with response interceptors, the callbacks will now always run after the interceptors (and wait for them to resolve in case they return a promise). Previously, the error callback was called before the responseError interceptor and the success callback was synchronously called after the response interceptor. E.g.:

var User = $resource('/api/users/:id', {id: '@id'}, {
  get: {
    method: 'get',
    interceptor: {
      response: function(response) {
        console.log('responseInterceptor-1');
        return $timeout(1000).then(function() {
          console.log('responseInterceptor-2');
          return response.resource;
        });
      },
      responseError: function(response) {
        console.log('responseErrorInterceptor-1');
        return $timeout(1000).then(function() {
          console.log('responseErrorInterceptor-2');
          return $q.reject('Ooops!');
        });
      }
    }
  }
});
var onSuccess = function(value) { console.log('successCallback', value); };
var onError = function(error) { console.log('errorCallback', error); };

// Assuming the following call is successful...
User.get({id: 1}, onSuccess, onError);
  // Old behavior:
  //   responseInterceptor-1
  //   successCallback, {/* Promise object */}
  //   responseInterceptor-2
  // New behavior:
  //   responseInterceptor-1
  //   responseInterceptor-2
  //   successCallback, {/* User object */}

// Assuming the following call returns an error...
User.get({id: 2}, onSuccess, onError);
  // Old behavior:
  //   errorCallback, {/* Response object */}
  //   responseErrorInterceptor-1
  //   responseErrorInterceptor-2
  // New behavior:
  //   responseErrorInterceptor-1
  //   responseErrorInterceptor-2
  //   errorCallback, Ooops!

Previously, calling a $resource method would synchronously call $http. Now, it will be called asynchronously (regardless if a request/requestError interceptor has been defined.

This is not expected to affect applications at runtime, since the overall operation is asynchronous already, but may affect assertions in tests. For example, if you want to assert that $http has been called with specific arguments as a result of a $resource call, you now need to run a $digest first, to ensure the (possibly empty) request interceptor promise has been resolved.

Before:

it('...', function() {
  $httpBackend.expectGET('/api/things').respond(...);
  var Things = $resource('/api/things');
  Things.query();

  expect($http).toHaveBeenCalledWith(...);
});

After:

it('...', function() {
  $httpBackend.expectGET('/api/things').respond(...);
  var Things = $resource('/api/things');
  Things.query();
  $rootScope.$digest();

  expect($http).toHaveBeenCalledWith(...);
});

$templateRequest:

Previously the tpload error was namespaced to $compile. If you have code that matches errors of the form [$compile:tpload] it will no longer run. You should change the code to match [$templateRequest:tpload].

The service now returns the result of $templateCache.put() when making a server request to the template. Previously it would return the content of the response directly. This now means if you are decorating $templateCache.put() to manipulate the template, you will now get this manipulated result also on the first $templateRequest rather than only on subsequent calls (when the template is retrived from the cache). In practice this should not affect any apps, as it is unlikely that they rely on the template being different in the first and subsequent calls.

$animate due to:

$animate.cancel(runner) now rejects the underlying promise and calls the catch() handler on the runner returned by $animate functions (enter, leave, move, addClass, removeClass, setClass, animate). Previously it would resolve the promise as if the animation had ended successfully.

Example:

var runner = $animate.addClass('red');
runner.then(function() { console.log('success')});
runner.catch(function() { console.log('cancelled')});

runner.cancel();

Pre-1.7.0, this logs ‘success’, 1.7.0 and later it logs ‘cancelled’. To migrate, add a catch() handler to your animation runners.

angular.isArray due to:

Previously, angular.isArray() was an alias for Array.isArray(). Therefore, objects that prototypally inherit from Array where not considered arrays. Now such objects are considered arrays too.

This change affects several other methods that use angular.isArray() under the hood, such as angular.copy(), angular.equals(), angular.forEach(), and angular.merge().

This in turn affects how dirty checking treats objects that prototypally inherit from Array (e.g. MobX observable arrays). AngularJS will now be able to handle these objects better when copying or watching.

**$sce** due to: - **[1e9ead](https://github.com/angular/angular.js/commit/1e9eadcd72dbbd5c67dae8328a63e535cfa91ff9)**: handle URL sanitization through the `$sce` service

If you use attrs.$set for URL attributes (a[href] and img[src]) there will no longer be any automated sanitization of the value. This is in line with other programmatic operations, such as writing to the innerHTML of an element.

If you are programmatically writing URL values to attributes from untrusted input then you must sanitize it yourself. You could write your own sanitizer or copy the private $$sanitizeUri service.

Note that values that have been passed through the $interpolate service within the URL or MEDIA_URL will have already been sanitized, so you would not need to sanitize these values again.

orderBy due to:

When using orderBy to sort arrays containing null values, the null values will be considered “greater than” all other values, except for undefined. Previously, they were sorted as strings. This will result in different (but more intuitive) sorting order.

Before:

orderByFilter(['a', undefined, 'o', null, 'z']);
//--> 'a', null, 'o', 'z', undefined

After:

orderByFilter(['a', undefined, 'o', null, 'z']);
//--> 'a', 'o', 'z', null, undefined

ngScenario due to:

The angular scenario runner end-to-end test framework has been removed from the project and will no longer be available on npm or bower starting with 1.7.0. It was deprecated and removed from the documentation in 2014. Applications that still use it should migrate to Protractor. Technically, it should also be possible to continue using an older version of the scenario runner, as the underlying APIs have not changed. However, we do not guarantee future compatibility.

form due to:

Forms will now set $submitted on child forms when they are submitted. For example: ``` <form name="parentform" ng-submit="$ctrl.submit()">

Submitting this form will set $submitted on "parentform" and "childform".
Previously, it was only set on "parentform".

This change was introduced because mixing form and ngForm does not create
logically separate forms, but rather something like input groups.
Therefore, child forms should inherit the submission state from their parent form.

### **ngAria** due to:
  - **[6d5ef3](https://github.com/angular/angular.js/commit/6d5ef34fc6a974cde73157ba94f9706723dd8f5b)**: do not set aria attributes on input[type="hidden"]

ngAria no longer sets aria-* attributes on input[type="hidden"] with ngModel.
This can affect apps that test for the presence of aria attributes on hidden inputs.
To migrate, remove these assertions.
In actual apps, this should not have a user-facing effect, as the previous behavior
was incorrect, and the new behavior is correct for accessibility.

### **ngModel, input** due to:
  - **[74b04c](https://github.com/angular/angular.js/commit/74b04c9403af4fc7df5b6420f22c9f45a3e84140)**: improve handling of built-in named parsers

*Custom* parsers that fail to parse on input types "email", "url", "number", "date", "month",
"time", "datetime-local", "week", do no longer set `ngModelController.$error[inputType]`, and
the `ng-invalid-[inputType]` class. Also, custom parsers on input type "range" do no
longer set `ngModelController.$error.number` and the `ng-invalid-number` class.

Instead, any custom parsers on these inputs set `ngModelController.$error.parse` and
`ng-invalid-parse`. This change was made to make distinguishing errors from built-in parsers
and custom parsers easier.

### **ngModelOptions** due to:
  - **[55ba44](https://github.com/angular/angular.js/commit/55ba44913e02650b56410aa9ab5eeea5d3492b68)**: add debounce catch-all + allow debouncing 'default' only

the 'default' key in 'debounce' now only debounces the default event, i.e. the event
that is added as an update trigger by the different input directives automatically.

Previously, it also applied to other update triggers defined in 'updateOn' that
did not have a corresponding key in the 'debounce'.

This behavior is now supported via a special wildcard / catch-all key: '*'.

See the following example:

Pre-1.7:
'mouseup' is also debounced by 500 milliseconds because 'default' is applied:

ng-model-options="{ updateOn: ‘default blur mouseup’, debounce: { ‘default’: 500, ‘blur’: 0 } }


1.7:
The pre-1.7 behavior can be re-created by setting '*' as a catch-all debounce value:

ng-model-options="{ updateOn: ‘default blur mouseup’, debounce: { ’*‘: 500, ’blur’: 0 } }


In contrast, when only 'default' is used, 'blur' and 'mouseup' are not debounced:

ng-model-options="{ updateOn: ‘default blur mouseup’, debounce: { ‘default’: 500 } }


### **input\[number\]** due to:
  - **[aa3f95](https://github.com/angular/angular.js/commit/aa3f951330ec7b10b43ea884d9b5754e296770ec)**: validate min/max against viewValue

`input[type=number]` with `ngModel` now validates the input for the `max`/`min` restriction against
the `ngModelController.$viewValue` instead of against the `ngModelController.$modelValue`.

This affects apps that use `$parsers` or `$formatters` to transform the input / model value.

If you rely on the $modelValue validation, you can overwrite the `min`/`max` validator from a custom directive, as seen in the following example directive definition object:

{ restrict: ‘A’, require: ‘ngModel’, link: function(scope, element, attrs, ctrl) { var maxValidator = ctrl.$validators.max;

ctrl.$validators.max = function(modelValue, viewValue) {
  return maxValidator(modelValue, modelValue);
};

} }


### **input** due to:
  - **[656c8f](https://github.com/angular/angular.js/commit/656c8fa8f23b1277cc5c214c4d0237f3393afa1e)**: listen on "change" instead of "click" for radio/checkbox ngModels

`input[radio]` and `input[checkbox]` now listen to the "change" event instead of the "click" event.
Most apps should not be affected, as "change" is automatically fired by browsers after "click"
happens.

Two scenarios might need migration:

- Custom click events:

Before this change, custom click event listeners on radio / checkbox would be called after the
input element and `ngModel` had been updated, unless they were specifically registered before
the built-in click handlers.
After this change, they are called before the input is updated, and can call event.preventDefault()
to prevent the input from updating.

If an app uses a click event listener that expects ngModel to be updated when it is called, it now
needs to register a change event listener instead.

- Triggering click events:

Conventional trigger functions:

The change event might not be fired when the input element is not attached to the document. This
can happen in **tests** that compile input elements and
trigger click events on them. Depending on the browser (Chrome and Safari) and the trigger method,
the change event will not be fired when the input isn't attached to the document.

Before:

```js
    it('should update the model', inject(function($compile, $rootScope) {
      var inputElm = $compile('<input type="checkbox" ng-model="checkbox" />')($rootScope);

      inputElm[0].click(); // Or different trigger mechanisms, such as jQuery.trigger()
      expect($rootScope.checkbox).toBe(true);
    });

With this patch, $rootScope.checkbox might not be true, because the click event hasn’t triggered the change event. To make the test, work append the inputElm to the app’s $rootElement, and the $rootElement to the $document.

After:

    it('should update the model', inject(function($compile, $rootScope, $rootElement, $document) {
      var inputElm = $compile('<input type="checkbox" ng-model="checkbox" />')($rootScope);

      $rootElement.append(inputElm);
      $document.append($rootElement);

      inputElm[0].click(); // Or different trigger mechanisms, such as jQuery.trigger()
      expect($rootScope.checkbox).toBe(true);
    });

triggerHandler():

If you are using this jQuery / jqLite function on the input elements, you don’t have to attach the elements to the document, but instead change the triggered event to “change”. This is because triggerHandler(event) only triggers the exact event when it has been added by jQuery / jqLite.

ngStyle due to:

Previously the use of deep watch by ng-style would trigger styles to be re-applied when nested state changed. Now only changes to direct properties of the watched object will trigger changes.

$compile due to:

Previously, the $compileProvider.preAssignBindingsEnabled flag was supported. The flag controlled whether bindings were available inside the controller constructor or only in the $onInit hook. The bindings are now no longer available in the constructor.

To migrate your code:

  1. If you haven’t invoked $compileProvider.preAssignBindingsEnabled() you don’t have to do anything to migrate.

  2. If you specified $compileProvider.preAssignBindingsEnabled(false), you can remove that statement - since AngularJS 1.6.0 this is the default so your app should still work even in AngularJS 1.6 after such removal. Afterwards, migrating to AngularJS 1.7.0 shouldn’t require any further action.

  3. If you specified $compileProvider.preAssignBindingsEnabled(true) you need to first migrate your code so that the flag can be flipped to false. The instructions on how to do that are available in the “Migrating from 1.5 to 1.6” guide: https://docs.angularjs.org/guide/migration#migrating-from-1-5-to-1-6 Afterwards, remove the $compileProvider.preAssignBindingsEnabled(true) statement.

In the unlikely case that an app relied on RESOURCE_URL whitelisting for the purpose of binding to the xlink:href property of SVG’s <a> or <image> elements and if the values do not pass the regular URL sanitization, they will break.

To fix this you need to ensure that the values used for binding to the affected xlink:href contexts are considered safe URLs, e.g. by whitelisting them in $compileProvider’s aHrefSanitizationWhitelist (for <a> elements) or imgSrcSanitizationWhitelist (for <image> elements).

Previously when a literal value was passed into a directive/component via one-way binding it would be watched with a deep watcher.

For example, for <my-component input="[a]">, a new instance of the array would be passed into the directive/component (and trigger $onChanges) not only if a changed but also if any sub property of a changed such as a.b or a.b.c.d.e etc.

This also means a new but equal value for a would NOT trigger such a change.

Now literal values use an input-based watch similar to other directive/component one-way bindings. In this context inputs are the non-constant parts of the literal. In the example above the input would be a. Changes are only triggered when the inputs to the literal change.

Previously, <base href="{{ $ctrl.baseUrl }}" /> would not require baseUrl to be trusted as a RESOURCE_URL. Now, baseUrl will be sent to $sce’s RESOURCE_URL checks. By default, it will break unless baseUrl is of the same origin as the application document.

Refer to the $sce API docs for more info on how to trust a value in a RESOURCE_URL context.

Also, concatenation in trusted contexts is not allowed, which means that the following won’t work: <base href="/something/{{ $ctrl.partialPath }}" />.

Either construct complex values in a controller (recommended):

this.baseUrl = '/something/' + this.partialPath;
<base href="{{ $ctrl.baseUrl }}" />

Or use string concatenation in the interpolation expression (not recommended except for the simplest of cases):

<base href="{{ '/something/' + $ctrl.partialPath }}" />

ngTouch due to:

The ngClick directive from the ngTouch module has been removed, and with it the corresponding $touchProvider and $touch service.

If you have included ngTouch v1.5.0 or higher in your application, and have not changed the value of $touchProvider.ngClickOverrideEnabled(), or injected and used the $touch service, then there are no migration steps for your code. Otherwise you must remove references to the provider and service.

The ngClick override directive had been deprecated and by default disabled since v1.5.0, because of buggy behavior in edge cases, and a general trend to avoid special touch based overrides of click events. In modern browsers, it should not be necessary to use a touch override library:

You can find out more in these articles: https://developers.google.com/web/updates/2013/12/300ms-tap-delay-gone-away https://developer.apple.com/library/content/releasenotes/General/WhatsNewInSafari/Articles/Safari_9_1.html#//apple_ref/doc/uid/TP40014305-CH10-SW8 https://blogs.msdn.microsoft.com/ie/2015/02/24/pointer-events-w3c-recommendation-interoperable-touch-and-removing-the-dreaded-300ms-tap-delay/

Angular due to:

The helper functions angular.lowercase and angular.uppercase have been removed.

These functions have been deprecated since 1.5.0. They are internally used, but should not be exposed as they contain special locale handling (for Turkish) to maintain internal consistency regardless of user-set locale.

Developers should generally use the built-ins toLowerCase and toUpperCase or toLocaleLowerCase and toLocaleUpperCase for special cases.

Further, we generally discourage using the angular.x helpers in application code.

$controller due to:

The option to instantiate controllers from constructors on the global window object has been removed. Likewise, the deprecated $controllerProvider.allowGlobals() method that could enable this behavior, has been removed.

This behavior had been deprecated since AngularJS v1.3.0, because polluting the global scope is bad. To migrate, remove the call to $controllerProvider.allowGlobals() in the config, and register your controller via the Module API or the $controllerProvider, e.g.

angular.module('myModule', []).controller('myController', function() {...});

angular.module('myModule', []).config(function($controllerProvider) {
  $controllerProvider.register('myController', function() {...});
});

$rootScope due to:

Previously when using $watchGroup the entries in newValues and oldValues represented the most recent change of each entry.

Now the entries in oldValues will always equal the newValues of the previous call of the listener. This means comparing the entries in newValues and oldValues can be used to determine which individual expressions changed.

For example $scope.$watchGroup(['a', 'b'], fn) would previously:

Action newValue oldValue
(init) [undefined, undefined] [undefined, undefined]
a=1 [1, undefined] [undefined, undefined]
a=2 [2, undefined] [1, undefined]
b=3 [2, 3] [1, undefined]

Now the oldValue will always equal the previous newValue:

Action newValue oldValue
(init) [undefined, undefined] [undefined, undefined]
a=1 [1, undefined] [undefined, undefined]
a=2 [2, undefined] [1, undefined]
b=3 [2, 3] [2, undefined]

Note the last call now shows a === 2 in the oldValues array.

This also makes the oldValue of one-time watchers more clear. Previously the oldValue of a one-time watcher would remain undefined forever. For example $scope.$watchGroup(['a', '::b'], fn) would previously:

Action newValue oldValue
(init) [undefined, undefined] [undefined, undefined]
a=1 [1, undefined] [undefined, undefined]
b=2 [1, 2] [undefined, undefined]
a=b=3 [3, 2] [1, undefined]

Where now the oldValue will always equal the previous newValue:

Action newValue oldValue
(init) [undefined, undefined] [undefined, undefined]
a=1 [1, undefined] [undefined, undefined]
b=2 [1, 2] [1, undefined]
a=b=3 [3, 2] [1, 2]

**interval *  * dueto :  −  *  * [a8bef9](https : //github.com/angular/angular.js/commit/a8bef95127775d83d80daa4617c33227c4b443d4) *  *  : throwwhentryingtocancelnoninterval promise

$interval.cancel() will throw an error if called with a promise that was not generated by $interval(). Previously, it would silently do nothing.

Before:

var promise = $interval(doSomething, 1000, 5).then(doSomethingElse);
$interval.cancel(promise);  // No error; interval NOT canceled.

After:

var promise = $interval(doSomething, 1000, 5).then(doSomethingElse);
$interval.cancel(promise);  // Throws error.

Correct usage:

var promise = $interval(doSomething, 1000, 5);
var newPromise = promise.then(doSomethingElse);
$interval.cancel(promise);  // Interval canceled.

**timeout *  * dueto :  −  *  * [336525](https : //github.com/angular/angular.js/commit/3365256502344970f86355d3ace1cb4251ae9828) *  *  : throwwhentryingtocancelnontimeout promise

$timeout.cancel() will throw an error if called with a promise that was not generated by $timeout(). Previously, it would silently do nothing.

Before:

var promise = $timeout(doSomething, 1000).then(doSomethingElse);
$timeout.cancel(promise);  // No error; timeout NOT canceled.

After:

var promise = $timeout(doSomething, 1000).then(doSomethingElse);
$timeout.cancel(promise);  // Throws error.

Correct usage:

var promise = $timeout(doSomething, 1000);
var newPromise = promise.then(doSomethingElse);
$timeout.cancel(promise);  // Timeout canceled.

# 1.6.10 crystalline-persuasion (2018-04-17)

Bug Fixes

New Features

# 1.6.9 fiery-basilisk (2018-02-02)

Bug Fixes

New Features

# 1.6.8 beneficial-tincture (2017-12-18)

Bug Fixes

New Features

# 1.6.7 imperial-backstroke (2017-11-24)

Bug Fixes

New Features

Performance Improvements

# 1.6.6 interdimensional-cable (2017-08-18)

Bug Fixes

New Features

# 1.6.5 toffee-salinization (2017-07-03)

Bug Fixes

New Features

Performance Improvements

# 1.6.4 phenomenal-footnote (2017-03-31)

Bug Fixes

New Features

# 1.6.3 scriptalicious-bootstrapping (2017-03-08)

Bug Fixes

New Features

# 1.6.2 llamacorn-lovehug (2017-02-07)

Bug Fixes

New Features

# 1.5.11 princely-quest (2017-01-13)

Bug Fixes

# 1.6.1 promise-rectification (2016-12-23)

Bug Fixes

Performance Improvements

# 1.5.10 asynchronous-synchronization (2016-12-15)

Bug Fixes

New Features

Performance Improvements

# 1.6.0 rainbow-tsunami (2016-12-08)

Here are the full changes for the release of 1.6.0 that are not already released in the 1.5.x branch, consolidating all the changes shown in the previous 1.6.0 release candidates.

New Features

Bug Fixes

Performance Improvements

Breaking Changes

Previously, $compileProvider.preAssignBindingsEnabled was set to true by default. This means bindings were pre-assigned on component/directive controller instances (which made them available inside the constructors). In AngularJS 1.5+ the place to put the initialization logic relying on bindings being present is the controller’s $onInit method.

To migrate follow the example below:

Before:

angular.module('myApp', [])
  .component('myComponent', {
    bindings: {value: '<'},
    controller: function() {
      this.doubleValue = this.value * 2;
    }
  });

After:

angular.module('myApp', [])
  .component('myComponent', {
    bindings: {value: '<'},
    controller: function() {
      this.$onInit = function() {
        this.doubleValue = this.value * 2;
      };
    }
  });

If you don’t have time to migrate the code at the moment, you can flip the setting back to true:

angular.module('myApp', [])
  .config(function($compileProvider) {
    $compileProvider.preAssignBindingsEnabled(true);
  })
  .component('myComponent', {
    bindings: {value: '<'},
    controller: function() {
      this.doubleValue = this.value * 2;
    }
  });

Don’t do this if you’re writing a library, though, as you shouldn’t change global configuration then.

When using input[radio], the checked status is now determined by doing a strict comparison between the value of the input and the ngModel.$viewValue. Previously, this was a non-strict comparison (==).

This means in the following examples the radio is no longer checked:

  <!-- this.selected = 0 -->
  <input type="radio" ng-model="$ctrl.selected" value="0" >

  <!-- this.selected = 0; this.value = false; -->
  <input type="radio" ng-model="$ctrl.selected" ng-value="$ctrl.value" >

The migration strategy is to convert values that matched with non-strict conversion so that they will match with strict conversion.

The programmatic API for ngModelOptions has changed. You must now read options via the ngModelController.$options.getOption(name) method, rather than accessing the option directly as a property of the ngModelContoller.$options object. This does not affect the usage in templates and only affects custom directives that might have been reading options for their own purposes.

One benefit of these changes, though, is that the ngModelControler.$options property is now guaranteed to be defined so there is no need to check before accessing.

So, previously:

var myOption = ngModelController.$options && ngModelController.$options['my-option'];

and now:

var myOption = ngModelController.$options.getOption('my-option');

jqLite due to:

Previously, keys passed to the data method were left untouched. Now they are internally camelCased similarly to how jQuery handles it, i.e. only single (!) hyphens followed by a lowercase letter get converted to an uppercase letter. This means keys a-b and aB represent the same data piece; writing to one of them will also be reflected if you ask for the other one.

If you use Angular with jQuery, it already behaved in this way so no changes are required on your part.

To migrate the code follow the examples below:

BEFORE:

/* 1 */
elem.data('my-key', 2);
elem.data('myKey', 3);

/* 2 */
elem.data('foo-bar', 42);
elem.data()['foo-bar']; // 42
elem.data()['fooBar']; // undefined

/* 3 */
elem.data()['foo-bar'] = 1;
elem.data()['fooBar'] = 2;
elem.data('foo-bar'); // 1

AFTER:

/* 1 */
// Rename one of the keys as they would now map to the same data slot.
elem.data('my-key', 2);
elem.data('my-key2', 3);

/* 2 */
elem.data('foo-bar', 42);
elem.data()['foo-bar']; // undefined
elem.data()['fooBar']; // 42

/* 3 */
elem.data()['foo-bar'] = 1;
elem.data()['fooBar'] = 2;
elem.data('foo-bar'); // 2

Before, when Angular was used without jQuery, the key passed to the css method was more heavily camelCased; now only a single (!) hyphen followed by a lowercase letter is getting transformed. This also affects APIs that rely on the css method, like ngStyle.

If you use Angular with jQuery, it already behaved in this way so no changes are needed on your part.

To migrate the code follow the example below:

Before:

HTML:

// All five versions used to be equivalent.
<div ng-style={background_color: 'blue'}></div>
<div ng-style={'background:color': 'blue'}></div>
<div ng-style={'background-color': 'blue'}></div>
<div ng-style={'background--color': 'blue'}></div>
<div ng-style={backgroundColor: 'blue'}></div>

JS:

// All five versions used to be equivalent.
elem.css('background_color', 'blue');
elem.css('background:color', 'blue');
elem.css('background-color', 'blue');
elem.css('background--color', 'blue');
elem.css('backgroundColor', 'blue');

// All five versions used to be equivalent.
var bgColor = elem.css('background_color');
var bgColor = elem.css('background:color');
var bgColor = elem.css('background-color');
var bgColor = elem.css('background--color');
var bgColor = elem.css('backgroundColor');

After:

HTML:

// Previous five versions are no longer equivalent but these two still are.
<div ng-style={'background-color': 'blue'}></div>
<div ng-style={backgroundColor: 'blue'}></div>

JS:

// Previous five versions are no longer equivalent but these two still are.
elem.css('background-color', 'blue');
elem.css('backgroundColor', 'blue');

// Previous five versions are no longer equivalent but these two still are.
var bgColor = elem.css('background-color');
var bgColor = elem.css('backgroundColor');

Previously, all boolean attributes were reflected into the corresponding property when calling a setter and from the corresponding property when calling a getter, even on elements that don’t treat those attributes in a special way. Now Angular doesn’t do it by itself, but relies on browsers to know when to reflect the property. Note that this browser-level conversion differs between browsers; if you need to dynamically change the state of an element, you should modify the property, not the attribute. See https://jquery.com/upgrade-guide/1.9/#attr-versus-prop- for a more detailed description about a related change in jQuery 1.9.

This change aligns jqLite with jQuery 3. To migrate the code follow the example below:

Before:

CSS:

input[checked="checked"] { ... }

JS:

elem1.attr('checked', 'checked');
elem2.attr('checked', false);

After:

CSS:

input:checked { ... }

JS:

elem1.prop('checked', true);
elem2.prop('checked', false);

Before, using the attr method with an empty string as a value would remove the boolean attribute. Now it sets it to its lowercase name as was happening for every non-empty string so far. The only two values that remove the boolean attribute are now null & false, just like in jQuery.

To migrate the code follow the example below:

Before:

elem.attr(booleanAttrName, '');

After:

elem.attr(booleanAttrName, false);

or:

elem.attr(booleanAttrName, null);

Invoking elem.attr(attributeName, null) would set the attributeName attribute value to a string "null", now it removes the attribute instead.

To migrate the code follow the example below:

Before:

elem.attr(attributeName, null);

After:

elem.attr(attributeName, "null");

For the jqLite element representing a select element in the multiple variant with no options chosen the .val() getter used to return null and now returns an empty array.

To migrate the code follow the example below:

Before:

HTML:

    <select multiple>
        <option>value 1</option>
        <option>value 2</option>
    </select>

JavaScript:

    var value = $element.val();
    if (value) {
        /* do something */
    }

After:

HTML:

    <select multiple>
        <option>value 1</option>
        <option>value 2</option>
    </select>

JavaScript:

    var value = $element.val();
    if (value.length > 0) {
        /* do something */
    }

ngModel due to:

Previously, only a literal false return would resolve as the synchronous validator failing. Now, all falsy JavaScript values are treated as failing the validator, as one would naturally expect.

Specifically, the values 0 (the number zero), null, NaN and '' (the empty string) used to be considered valid (passing) and they are now considered invalid (failing). The value undefined was treated similarly to a pending asynchronous validator, causing the validation to be pending. undefined is also now considered invalid.

To migrate, make sure your synchronous validators are returning either a literal true or a literal false value. For most code, we expect this to already be the case. Only a very small subset of projects will be affected.

Namely, anyone using undefined or any falsy value as a return will now see their validation failing, whereas previously falsy values other than undefined would have been seen as passing and undefined would have been seen as pending.

The use of prototype methods instead of new methods per instance removes the ability to pass NgModelController and FormController methods without context.

For example

$scope.$watch('something', myNgModelCtrl.$render)

will no longer work because the $render method is passed without any context. This must now be replaced with

$scope.$watch('something', function() {
  myNgModelCtrl.$render();
})

or possibly by using Function.prototype.bind or angular.bind.

aria/ngModel due to:

Custom checkbox-shaped controls (e.g. checkboxes, menuitemcheckboxes), no longer have a custom $isEmpty() method on their NgModelController that checks for value === false. Unless overwritten, the default $isEmpty() method will be used, which treats undefined, null, NaN and '' as “empty”.

Note: The $isEmpty() method is used to determine if the checkbox is checked (“not empty” means “checked”) and thus it can indirectly affect other things, such as the control’s validity with respect to the required validator (e.g. “empty” + “required” –> “invalid”).

Before:

var template = '<my-checkbox role="checkbox" ng-model="value"></my-checkbox>';
var customCheckbox = $compile(template)(scope);
var ctrl = customCheckbox.controller('ngModel');

scope.$apply('value = false');
console.log(ctrl.$isEmpty());   //--> true

scope.$apply('value = true');
console.log(ctrl.$isEmpty());   //--> false

scope.$apply('value = undefined'/* or null or NaN or '' */);
console.log(ctrl.$isEmpty());   //--> false

After:

var template = '<my-checkbox role="checkbox" ng-model="value"></my-checkbox>';
var customCheckbox = $compile(template)(scope);
var ctrl = customCheckbox.controller('ngModel');

scope.$apply('value = false');
console.log(ctrl.$isEmpty());   //--> false

scope.$apply('value = true');
console.log(ctrl.$isEmpty());   //--> false

scope.$apply('value = undefined'/* or null or NaN or '' */);
console.log(ctrl.$isEmpty());   //--> true

– If you want to have a custom $isEmpty() method, you need to overwrite the default. For example:

.directive('myCheckbox', function myCheckboxDirective() {
  return {
    require: 'ngModel',
    link: function myCheckboxPostLink(scope, elem, attrs, ngModelCtrl) {
      ngModelCtrl.$isEmpty = function myCheckboxIsEmpty(value) {
        return !value;   // Any falsy value means "empty"

        // Or to restore the previous behavior:
        // return value === false;
      };
    }
  };
})

$http due to:

$http’s deprecated custom callback methods - success() and error() - have been removed. You can use the standard then()/catch() promise methods instead, but note that the method signatures and return values are different.

success(fn) can be replaced with then(fn), and error(fn) can be replaced with either then(null, fn) or catch(fn).

Before:

$http(...).
  success(function onSuccess(data, status, headers, config) {
    // Handle success
    ...
  }).
  error(function onError(data, status, headers, config) {
    // Handle error
    ...
  });

After:

$http(...).
  then(function onSuccess(response) {
    // Handle success
    var data = response.data;
    var status = response.status;
    var statusText = response.statusText;
    var headers = response.headers;
    var config = response.config;
    ...
  }, function onError(response) {
    // Handle error
    var data = response.data;
    var status = response.status;
    var statusText = response.statusText;
    var headers = response.headers;
    var config = response.config;
    ...
  });

// or

$http(...).
  then(function onSuccess(response) {
    // Handle success
    var data = response.data;
    var status = response.status;
    var statusText = response.statusText;
    var headers = response.headers;
    var config = response.config;
    ...
  }).
  catch(function onError(response) {
    // Handle error
    var data = response.data;
    var status = response.status;
    var statusText = response.statusText;
    var headers = response.headers;
    var config = response.config;
    ...
  });

Note: There is a subtle difference between the variations showed above. When using $http(...).success(onSuccess).error(onError) or $http(...).then(onSuccess, onError), the onError() callback will only handle errors/rejections produced by the $http() call. If the onSuccess() callback produces an error/rejection, it won’t be handled by onError() and might go unnoticed. In contrast, when using $http(...).then(onSuccess).catch(onError), onError() will handle errors/rejections produced by both $http() and onSuccess().

You can no longer use the JSON_CALLBACK placeholder in your JSONP requests. Instead you must provide the name of the query parameter that will pass the callback via the jsonpCallbackParam property of the config object, or app-wide via the $http.defaults.jsonpCallbackParam property, which is "callback" by default.

Before this change:

$http.json('trusted/url?callback=JSON_CALLBACK');
$http.json('other/trusted/url', {params: {cb:'JSON_CALLBACK'}});

After this change:

$http.json('trusted/url');
$http.json('other/trusted/url', {jsonpCallbackParam:'cb'});

All JSONP requests now require the URL to be trusted as resource URLs. There are two approaches to trust a URL:

Whitelisting with the $sceDelegateProvider.resourceUrlWhitelist() method.

You configure this list in a module configuration block:

appModule.config(['$sceDelegateProvider', function($sceDelegateProvider) {
  $sceDelegateProvider.resourceUrlWhitelist([
    // Allow same origin resource loads.
    'self',
    // Allow JSONP calls that match this pattern
    'https://some.dataserver.com/**.jsonp?**'
  ]);
}]);

Explicitly trusting the URL via the $sce.trustAsResourceUrl(url) method.

You can pass a trusted object instead of a string as a URL to the $http service:

var promise = $http.jsonp($sce.trustAsResourceUrl(url));

HTTP requests now update the outstanding request count synchronously. Previously the request count would not have been updated until the request to the server is actually in flight. Now the request count is updated before the async interceptor is called.

The new behaviour is correct but it may change the expected behaviour in a small number of e2e test cases where an async request interceptor is being used.

$q due to:

Previously, throwing an error from a promise’s onFulfilled or onRejection handlers, would result in passing the error to the $exceptionHandler() (in addition to rejecting the promise with the error as reason).

Now, a thrown error is treated exactly the same as a regular rejection. This applies to all services/controllers/filters etc that rely on $q (including built-in services, such as $http and $route). For example, $http’s transformRequest/Response functions or a route’s redirectTo function as well as functions specified in a route’s resolve object, will no longer result in a call to $exceptionHandler() if they throw an error. Other than that, everything will continue to behave in the same way; i.e. the promises will be rejected, route transition will be cancelled, $routeChangeError events will be broadcasted etc.

Unhandled rejected promises will be logged to $exceptionHandler.

Tests that depend on specific order or number of messages in $exceptionHandler will need to handle rejected promises report.

ngTransclude due to:

Previously whitespace only transclusion would be treated as the transclusion being “not empty”, which meant that fallback content was not used in that case.

Now if you only provide whitespace as the transclusion content, it will be assumed to be empty and the fallback content will be used instead.

If you really do want whitespace then you can force it to be used by adding a comment to the whitespace.

Previously this would not fallback to default content:

<some-component>
</some-component>

Now the whitespace between the opening and closing tags is treated as empty. To force the previous behaviour simply add a comment:

<some-component><!-- -->
</some-component>

$compile due to:

Note: Everything described below affects IE11 only.

Previously, consecutive text nodes would not get merged if they had no parent. They will now, which might have unexpected side effects in the following cases:

  1. Passing an array or jqLite/jQuery collection of parent-less text nodes to $compile directly:

    // Assuming:
    var textNodes = [
      document.createTextNode('{{'),
      document.createTextNode('"foo:"'),
      document.createTextNode('}}')
    ];
    var compiledNodes = $compile(textNodes)($rootScope);
    
    // Before:
    console.log(compiledNodes.length);   // 3
    console.log(compiledNodes.text());   // {{'foo'}}
    
    // After:
    console.log(compiledNodes.length);   // 1
    console.log(compiledNodes.text());   // foo
    
    // To get the old behavior, compile each node separately:
    var textNodes = [
      document.createTextNode('{{'),
      document.createTextNode('"foo"'),
      document.createTextNode('}}')
    ];
    var compiledNodes = angular.element(textNodes.map(function (node) {
      return $compile(node)($rootScope)[0];
    }));
  2. Using multi-slot transclusion with non-consecutive, default-content text nodes (that form interpolated expressions when merged):

    // Assuming the following component:
    .component('someThing', {
      template: '<ng-transclude><!-- Default content goes here --></ng-transclude>'
      transclude: {
        ignored: 'veryImportantContent'
      }
    })
    <!-- And assuming the following view: -->
    <some-thing>
      {{
      <very-important-content>Nooot</very-important-content>
      'foo'}}
    </some-thing>
    
    <!-- Before: -->
    <some-thing>
      <ng-transclude>
        {{       <-- Two separate
        'foo'}}  <-- text nodes
      </ng-transclude>
    </some-thing>
    
    <!-- After: -->
    <some-thing>
      <ng-transclude>
        foo  <-- The text nodes were merged into `{{'foo'}}`, which was then interpolated
      </ng-transclude>
    </some-thing>
    
    <!-- To (visually) get the old behavior, wrap top-level text nodes on -->
    <!-- multi-slot transclusion directives into `<span>` elements; e.g.: -->
    <some-thing>
      <span>{{</span>
      <very-important-content>Nooot</very-important-content>
      <span>'foo'}}</span>
    </some-thing>
    
    <!-- Result: -->
    <some-thing>
      <ng-transclude>
        <span>{{</span>       <-- Two separate
        <span>'foo'}}</span>  <-- nodes
      </ng-transclude>
    </some-thing>

Using interpolation in any on* event attributes (e.g. <button onclick="{{myVar}}">) will now throw the “nodomevents” error at compile time. Previously the nodomevents was thrown at link time. The new behavior makes it consistent with the “selmulti” error. The breaking change should be rare, as it relates to incorrect API use that should not make it to production apps in the first place.

link[href] attributes are now protected via $sce, which prevents interpolated values that fail the RESOURCE_URL context tests from being used in interpolation.

For example if the application is running at https://docs.angularjs.org then the following will fail:

<link href="{{ 'http://mydomain.org/unsafe.css' }}" rel="stylesheet">

By default, RESOURCE_URL safe URLs are only allowed from the same domain and protocol as the application document.

To use URLs from other domains and/or protocols, you may either whitelist them or wrap it into a trusted value by calling $sce.trustAsResourceUrl(url).

White-space in attributes is no longer trimmed automatically. This includes leading and trailing white-space, and attributes that are purely white-space.

To migrate, attributes that require trimming must now be trimmed manually.

A common cases where stray white-space can cause problems is when attribute values are compared, for example in an $observer:

Before:

$attrs.$observe('myAttr', function(newVal) {
  if (newVal === 'false') ...
});

To migrate, the attribute value should be trimmed manually:

$attrs.$observe('myAttr', function(newVal) {
  if (newVal.trim() === 'false') ...
});

Note that $parse trims expressions automatically, so attributes with expressions (e.g. directive bindings) are unlikely to be affected by stray white-space.

ngRoute due to:

In cases where ngView was loaded asynchronously, $route (and its dependencies; e.g. $location) might also have been instantiated asynchronously. After this change, $route (and its dependencies) will - by default - be instantiated early on.

Although this is not expected to have unwanted side-effects in normal application behavior, it may affect your unit tests: When testing a module that (directly or indirectly) depends on ngRoute, a request will be made for the default route’s template. If not properly “trained”, $httpBackend will complain about this unexpected request.

You can restore the previous behavior (and avoid unexpected requests in tests), by using $routeProvider.eagerInstantiationEnabled(false).

The $route service no longer instantiates controllers nor calls resolves or template functions for routes that have a redirectTo unless the redirectTo is a function that returns undefined.

Previously, if redirectTo was a function that threw an Error, execution was aborted without firing a $routeChangeError event. Now, if a redirectTo function throws an Error, a $routeChangeError event will be fired.

ngMock due to:

Calling $httpBackend.verifyNoOutstandingRequest() will trigger a digest. This will ensure that requests fired asynchronously will also be detected (without the need to manually trigger a digest). This is not expected to affect the majority of test-suites. Most of the time, a digest is (directly or indirectly) triggered anyway, before calling verifyNoOutstandingRequest(). In the unlikely case that a test needs to verify the timing of a request with respect to the digest cycle, you should rely on other means, such as mocking and/or spying.

It is no longer valid to explicitly pass undefined as the url argument to any of the $httpBackend.when...() and $httpBackend.expect...() methods.

While this argument is optional, it must have a defined value if it is provided.

Previously passing an explicit undefined value was ignored but this lead to invalid tests passing unexpectedly.

ngAria due to:

If you were explicitly setting the value of the bindKeypress flag, you need to change your code to use bindKeydown instead.

Before: $ariaProvider.config({bindKeypress: xyz}) After: $ariaProvider.config({bindKeydown: xyz})

Note: If the element already has any of the ngKeydown/ngKeyup/ngKeypress directives, ngAria will not bind to the keydown event, since it assumes that the developer has already taken care of keyboard interaction for that element.

Although it is not expected to affect many applications, it might be desirable to keep the previous behavior of binding to the keypress event instead of the keydown. In that case, you need to manually use the ngKeypress directive (in addition to ngClick).

Before:

<div ng-click="onClick()">
  I respond to `click` and `keypress` (not `keydown`)
</div>

After:

<div ng-click="onClick()" ng-keypress="onClick()">
  I respond to `click` and `keypress` (not `keydown`)
</div>
<!-- OR -->
<div ng-click="onClick()">
  I respond to `click` and `keydown` (not `keypress`)
</div>

Finally, it is possible that this change affects your unit or end-to-end tests. If you are currently expecting your custom buttons to automatically respond to the keypress event (due to ngAria), you need to change the tests to trigger keydown events instead.

ngAria will no longer add the “role” attribute to native control elements (textarea, button, select, summary, details, a, and input). Previously, “role” was not added to input, but all others in the list.

This should not affect accessibility, because native inputs are accessible by default, but it might affect applications that relied on the “role” attribute being present (e.g. for styling or as directive attributes).

$resource due to:

All owned properties of the params object that are not used to replace URL params, will be passed to $http as config.params (to be used as query parameters in the URL), even if Object.prototype has a property with the same name. E.g.:

Before:

var Foo = $resource('/foo/:id');
Foo.get({id: 42, bar: 'baz', toString: 'hmm'});
    // URL: /foo/42?bar=baz
    // Note that `toString` is _not_ included in the query,
    // because `Object.prototype.toString` is defined :(

After:

var Foo = $resource('/foo/:id');
Foo.get({id: 42, bar: 'baz', toString: 'hmm'});
    // URL: /foo/42?bar=baz&toString=hmm
    // Note that `toString` _is_ included in the query, as expected :)

Although it shouldn’t matter in practice (since both the encoded and the unencoded ; character would be interpreted identically by the server), this change could break some tests: For example, where $httpBackend was set up to expect an encoded ; character, but the request is made to the URL with an unencoded ; character.

select due to:

<option> elements added to <select ng-model> via ngValue now add their values in hash form, i.e. <option ng-value="myString"> becomes <option ng-value="myString" value="string:myString">.

This is done to support binding options with values of any type to selects.

This should rarely affect applications, as the values of options are usually not relevant to the application logic, but it’s possible that option values are checked in tests.

Option elements will no longer set their value attribute from their text value when their select element has no ngModel associated. Setting the value is only needed for the select directive to match model values and options. If no ngModel is present, the select directive doesn’t need it.

This should not affect many applications as the behavior was undocumented and not part of a public API. It also has no effect on the usual HTML5 behavior that sets the select value to the option text if the option does not provide a value attribute.

ngBind due to:

ngBind now uses the same logic as $interpolate (i.e. {{myString}}) when binding, which means values other than strings are now transformed as following: - null / undefined become empty string - with an object’s custom toString() function, except if the object is a Date, Array, or Number - otherwise with JSON.stringify

Previously, ngBind would always use toString().

The following examples show the different output:

$scope.myPlainObject = {a: 1, b: 2};
$scope.myCustomObject = {a: 1, b: 2, toString: function() {return 'a+b';}};

Plain Object:

<!-- Before: -->
<span ng-bind="myPlainObject">[object Object]</span>

<!-- After: -->
<span ng-bind="myPlainObject">{'a':1,'b':2}</span>

Object with custom toString():

<!-- Before: -->
<span ng-bind="myCustomObject">[object Object]</span>

<!-- After: -->
<span ng-bind="myCustomObject">a+b</span>

If you want the output of toString(), you can use it directly on the value in ngBind:

<span ng-bind="myObject.toString()">[object Object]</span>

$interpolate due to:

When converting values to strings, interpolation now uses a custom toString() function on objects that are not Number, Array or Date (custom means that the toString function is not the same as Object.prototype.toString). Otherwise, interpolation uses JSON.stringify() as usual.

Should you have a custom toString() function but still want the output of JSON.stringify(), migrate as shown in the following examples:

Before:

<span>{{myObject}}</span>

After - use the json filter to stringify the object:

<span>{{myObject | json}}</span>

loader due to:

module.decorator declarations are now processed as part of the module.config queue and may result in providers being decorated in a different order if module.config blocks are also used to decorate providers via $provide.decorator.

For example, consider the following declaration order in which ‘theFactory’ is decorated by both a module.decorator and a $provide.decorator:

angular
  .module('theApp', [])
  .factory('theFactory', theFactoryFn)
  .config(function($provide) {
    $provide.decorator('theFactory', provideDecoratorFn);
  })
  .decorator('theFactory', moduleDecoratorFn);

Prior to this fix, ‘theFactory’ provider would be decorated in the following order: 1. moduleDecoratorFn 2. provideDecoratorFn

The result of this fix changes the order in which ‘theFactory’ is decorated because now module.decorator declarations are processed in the same order as module.config declarations: 1. provideDecoratorFn 2. moduleDecoratorFn

$location due to:

The hash-prefix for $location hash-bang URLs has changed from the empty string "" to the bang “!”. If your application does not use HTML5 mode or is being run on browsers that do not support HTML5 mode, and you have not specified your own hash-prefix then client side URLs will now contain a “!” prefix. For example, rather than mydomain.com/#/a/b/c will become mydomain.com/#!/a/b/c.

If you actually wanted to have no hash-prefix then you should configure this by adding a configuration block to you application:

appModule.config(['$locationProvider', function($locationProvider) {
  $locationProvider.hashPrefix('');
}]);

input[type=range] due to:

Due to the way that input[type=range] elements behave this feature modifies the behavior of such elements when bound to ngModel:

input[type=number] due to:

Number inputs that use ngModel and specify a step constraint (via step/ngStep attributes) will now have a new validator (step), which will verify that the current value is valid under the step constraint (according to the spec). Previously, the step constraint was ignored by ngModel, treating values as valid even when there was a step-mismatch.

If you want to restore the previous behavior (use the step attribute while disabling step validation), you can overwrite the built-in step validator with a custom directive. For example:

// For all `input` elements...
.directive('input', function() {
  return {
    restrict: 'E',
    require: '?ngModel',
    link: function (scope, elem, attrs, ngModelCtrl) {
      // ...that are of type "number" and have `ngModel`...
      if ((attrs.type === 'number') && ngModelCtrl) {
        // ...remove the `step` validator.
        delete ngModelCtrl.$validators.step;
      }
    }
  };
})

# 1.6.0-rc.2 safety-insurance (2016-11-24)

Security Fixes

Bug Fixes

Performance Improvements

# 1.5.9 timeturning-lockdown (2016-11-24)

This is an interim release primarily to publish some security fixes, in particular a modification to ensure that AngularJS can pass the linter checks for Mozilla add-ons.

Security Fixes

New Features

Bug Fixes

Performance Improvements

# 1.6.0-rc.1 proximity-warning (2016-11-21)

New Features

Bug Fixes

Reverts

Performance Improvements

Breaking Changes

Previously, $compileProvider.preAssignBindingsEnabled was set to true by default. This means bindings were pre-assigned in component constructors. In AngularJS 1.5+ the place to put the initialization logic relying on bindings being present is the controller $onInit method.

To migrate follow the example below:

Before:

angular.module('myApp', [])
  .component('myComponent', {
    bindings: {value: '<'},
    controller: function() {
      this.doubleValue = this.value * 2;
    }
  });

After:

angular.module('myApp', [])
  .component('myComponent', {
    bindings: {value: '<'},
    controller: function() {
      this.$onInit = function() {
        this.doubleValue = this.value * 2;
      };
    }
  });

If you don’t have time to migrate the code at the moment, you can flip the setting back to true:

angular.module('myApp', [])
  .config(function($compileProvider) {
    $compileProvider.preAssignBindingsEnabled(true);
  })
  .component('myComponent', {
    bindings: {value: '<'},
    controller: function() {
      this.doubleValue = this.value * 2;
    }
  });

Don’t do this if you’re writing a library, though, as you shouldn’t change global configuration then.

When using input[radio], the checked status is now determined by doing a strict comparison between the value of the input and the ngModel.$viewValue. Previously, this was a non-strict comparison (==).

This means in the following examples the radio is no longer checked:

  <!-- this.selected = 0 -->
  <input type="radio" ng-model="$ctrl.selected" value="0" >

  <!-- this.selected = 0; this.value = false; -->
  <input type="radio" ng-model="$ctrl.selected" ng-value="$ctrl.value" >

The migration strategy is to convert values that matched with non-strict conversion so that they will match with strict conversion.

The programmatic API for ngModelOptions has changed. You must now read options via the ngModelController.$options.getOption(name) method, rather than accessing the option directly as a property of the ngModelContoller.$options object. This does not affect the usage in templates and only affects custom directives that might have been reading options for their own purposes.

One benefit of these changes, though, is that the ngModelControler.$options property is now guaranteed to be defined so there is no need to check before accessing.

So, previously:

var myOption = ngModelController.$options && ngModelController.$options['my-option'];

and now:

var myOption = ngModelController.$options.getOption('my-option');

# 1.6.0-rc.0 bracing-vortex (2016-10-26)

Major notes

Please read the Sandbox Removal Blog Post.

Bug Fixes

New Features

Performance Improvements

Breaking Changes

jqLite due to:

Previously, keys passed to the data method were left untouched. Now they are internally camelCased similarly to how jQuery handles it, i.e. only single (!) hyphens followed by a lowercase letter get converted to an uppercase letter. This means keys a-b and aB represent the same data piece; writing to one of them will also be reflected if you ask for the other one.

If you use Angular with jQuery, it already behaved in this way so no changes are required on your part.

To migrate the code follow the examples below:

BEFORE:

/* 1 */
elem.data('my-key', 2);
elem.data('myKey', 3);

/* 2 */
elem.data('foo-bar', 42);
elem.data()['foo-bar']; // 42
elem.data()['fooBar']; // undefined

/* 3 */
elem.data()['foo-bar'] = 1;
elem.data()['fooBar'] = 2;
elem.data('foo-bar'); // 1

AFTER:

/* 1 */
// Rename one of the keys as they would now map to the same data slot.
elem.data('my-key', 2);
elem.data('my-key2', 3);

/* 2 */
elem.data('foo-bar', 42);
elem.data()['foo-bar']; // undefined
elem.data()['fooBar']; // 42

/* 3 */
elem.data()['foo-bar'] = 1;
elem.data()['fooBar'] = 2;
elem.data('foo-bar'); // 2

Before, when Angular was used without jQuery, the key passed to the css method was more heavily camelCased; now only a single (!) hyphen followed by a lowercase letter is getting transformed. This also affects APIs that rely on the css method, like ngStyle.

If you use Angular with jQuery, it already behaved in this way so no changes are needed on your part.

To migrate the code follow the example below:

Before:

HTML:

// All five versions used to be equivalent.
<div ng-style={background_color: 'blue'}></div>
<div ng-style={'background:color': 'blue'}></div>
<div ng-style={'background-color': 'blue'}></div>
<div ng-style={'background--color': 'blue'}></div>
<div ng-style={backgroundColor: 'blue'}></div>

JS:

// All five versions used to be equivalent.
elem.css('background_color', 'blue');
elem.css('background:color', 'blue');
elem.css('background-color', 'blue');
elem.css('background--color', 'blue');
elem.css('backgroundColor', 'blue');

// All five versions used to be equivalent.
var bgColor = elem.css('background_color');
var bgColor = elem.css('background:color');
var bgColor = elem.css('background-color');
var bgColor = elem.css('background--color');
var bgColor = elem.css('backgroundColor');

After:

HTML:

// Previous five versions are no longer equivalent but these two still are.
<div ng-style={'background-color': 'blue'}></div>
<div ng-style={backgroundColor: 'blue'}></div>

JS:

// Previous five versions are no longer equivalent but these two still are.
elem.css('background-color', 'blue');
elem.css('backgroundColor', 'blue');

// Previous five versions are no longer equivalent but these two still are.
var bgColor = elem.css('background-color');
var bgColor = elem.css('backgroundColor');

Previously, all boolean attributes were reflected into the corresponding property when calling a setter and from the corresponding property when calling a getter, even on elements that don’t treat those attributes in a special way. Now Angular doesn’t do it by itself, but relies on browsers to know when to reflect the property. Note that this browser-level conversion differs between browsers; if you need to dynamically change the state of an element, you should modify the property, not the attribute. See https://jquery.com/upgrade-guide/1.9/#attr-versus-prop- for a more detailed description about a related change in jQuery 1.9.

This change aligns jqLite with jQuery 3. To migrate the code follow the example below:

Before:

CSS:

input[checked="checked"] { ... }

JS:

elem1.attr('checked', 'checked');
elem2.attr('checked', false);

After:

CSS:

input:checked { ... }

JS:

elem1.prop('checked', true);
elem2.prop('checked', false);

Before, using the attr method with an empty string as a value would remove the boolean attribute. Now it sets it to its lowercase name as was happening for every non-empty string so far. The only two values that remove the boolean attribute are now null & false, just like in jQuery.

To migrate the code follow the example below:

Before:

elem.attr(booleanAttrName, '');

After:

elem.attr(booleanAttrName, false);

or:

elem.attr(booleanAttrName, null);

Invoking elem.attr(attributeName, null) would set the attributeName attribute value to a string "null", now it removes the attribute instead.

To migrate the code follow the example below:

Before:

elem.attr(attributeName, null);

After:

elem.attr(attributeName, "null");

For the jqLite element representing a select element in the multiple variant with no options chosen the .val() getter used to return null and now returns an empty array.

To migrate the code follow the example below:

Before:

HTML:

    <select multiple>
        <option>value 1</option>
        <option>value 2</option>
    </select>

JavaScript:

    var value = $element.val();
    if (value) {
        /* do something */
    }

After:

HTML:

    <select multiple>
        <option>value 1</option>
        <option>value 2</option>
    </select>

JavaScript:

    var value = $element.val();
    if (value.length > 0) {
        /* do something */
    }

ngModel due to:

Previously, only a literal false return would resolve as the synchronous validator failing. Now, all falsy JavaScript values are treated as failing the validator, as one would naturally expect.

Specifically, the values 0 (the number zero), null, NaN and '' (the empty string) used to be considered valid (passing) and they are now considered invalid (failing). The value undefined was treated similarly to a pending asynchronous validator, causing the validation to be pending. undefined is also now considered invalid.

To migrate, make sure your synchronous validators are returning either a literal true or a literal false value. For most code, we expect this to already be the case. Only a very small subset of projects will be affected.

Namely, anyone using undefined or any falsy value as a return will now see their validation failing, whereas previously falsy values other than undefined would have been seen as passing and undefined would have been seen as pending.

The use of prototype methods instead of new methods per instance removes the ability to pass NgModelController and FormController methods without context.

For example

$scope.$watch('something', myNgModelCtrl.$render)

will no longer work because the $render method is passed without any context. This must now be replaced with

$scope.$watch('something', function() {
  myNgModelCtrl.$render();
})

or possibly by using Function.prototype.bind or angular.bind.

aria/ngModel due to:

Custom checkbox-shaped controls (e.g. checkboxes, menuitemcheckboxes), no longer have a custom $isEmpty() method on their NgModelController that checks for value === false. Unless overwritten, the default $isEmpty() method will be used, which treats undefined, null, NaN and '' as “empty”.

Note: The $isEmpty() method is used to determine if the checkbox is checked (“not empty” means “checked”) and thus it can indirectly affect other things, such as the control’s validity with respect to the required validator (e.g. “empty” + “required” –> “invalid”).

Before:

var template = '<my-checkbox role="checkbox" ng-model="value"></my-checkbox>';
var customCheckbox = $compile(template)(scope);
var ctrl = customCheckbox.controller('ngModel');

scope.$apply('value = false');
console.log(ctrl.$isEmpty());   //--> true

scope.$apply('value = true');
console.log(ctrl.$isEmpty());   //--> false

scope.$apply('value = undefined'/* or null or NaN or '' */);
console.log(ctrl.$isEmpty());   //--> false

After:

var template = '<my-checkbox role="checkbox" ng-model="value"></my-checkbox>';
var customCheckbox = $compile(template)(scope);
var ctrl = customCheckbox.controller('ngModel');

scope.$apply('value = false');
console.log(ctrl.$isEmpty());   //--> false

scope.$apply('value = true');
console.log(ctrl.$isEmpty());   //--> false

scope.$apply('value = undefined'/* or null or NaN or '' */);
console.log(ctrl.$isEmpty());   //--> true

– If you want to have a custom $isEmpty() method, you need to overwrite the default. For example:

.directive('myCheckbox', function myCheckboxDirective() {
  return {
    require: 'ngModel',
    link: function myCheckboxPostLink(scope, elem, attrs, ngModelCtrl) {
      ngModelCtrl.$isEmpty = function myCheckboxIsEmpty(value) {
        return !value;   // Any falsy value means "empty"

        // Or to restore the previous behavior:
        // return value === false;
      };
    }
  };
})

$http due to:

$http’s deprecated custom callback methods - success() and error() - have been removed. You can use the standard then()/catch() promise methods instead, but note that the method signatures and return values are different.

success(fn) can be replaced with then(fn), and error(fn) can be replaced with either then(null, fn) or catch(fn).

Before:

$http(...).
  success(function onSuccess(data, status, headers, config) {
    // Handle success
    ...
  }).
  error(function onError(data, status, headers, config) {
    // Handle error
    ...
  });

After:

$http(...).
  then(function onSuccess(response) {
    // Handle success
    var data = response.data;
    var status = response.status;
    var statusText = response.statusText;
    var headers = response.headers;
    var config = response.config;
    ...
  }, function onError(response) {
    // Handle error
    var data = response.data;
    var status = response.status;
    var statusText = response.statusText;
    var headers = response.headers;
    var config = response.config;
    ...
  });

// or

$http(...).
  then(function onSuccess(response) {
    // Handle success
    var data = response.data;
    var status = response.status;
    var statusText = response.statusText;
    var headers = response.headers;
    var config = response.config;
    ...
  }).
  catch(function onError(response) {
    // Handle error
    var data = response.data;
    var status = response.status;
    var statusText = response.statusText;
    var headers = response.headers;
    var config = response.config;
    ...
  });

Note: There is a subtle difference between the variations showed above. When using $http(...).success(onSuccess).error(onError) or $http(...).then(onSuccess, onError), the onError() callback will only handle errors/rejections produced by the $http() call. If the onSuccess() callback produces an error/rejection, it won’t be handled by onError() and might go unnoticed. In contrast, when using $http(...).then(onSuccess).catch(onError), onError() will handle errors/rejections produced by both $http() and onSuccess().

You can no longer use the JSON_CALLBACK placeholder in your JSONP requests. Instead you must provide the name of the query parameter that will pass the callback via the jsonpCallbackParam property of the config object, or app-wide via the $http.defaults.jsonpCallbackParam property, which is "callback" by default.

Before this change:

$http.json('trusted/url?callback=JSON_CALLBACK');
$http.json('other/trusted/url', {params: {cb:'JSON_CALLBACK'}});

After this change:

$http.json('trusted/url');
$http.json('other/trusted/url', {jsonpCallbackParam:'cb'});

All JSONP requests now require the URL to be trusted as resource URLs. There are two approaches to trust a URL:

Whitelisting with the $sceDelegateProvider.resourceUrlWhitelist() method.

You configure this list in a module configuration block:

appModule.config(['$sceDelegateProvider', function($sceDelegateProvider) {
  $sceDelegateProvider.resourceUrlWhitelist([
    // Allow same origin resource loads.
    'self',
    // Allow JSONP calls that match this pattern
    'https://some.dataserver.com/**.jsonp?**'
  ]);
}]);

Explicitly trusting the URL via the $sce.trustAsResourceUrl(url) method.

You can pass a trusted object instead of a string as a URL to the $http service:

var promise = $http.jsonp($sce.trustAsResourceUrl(url));

HTTP requests now update the outstanding request count synchronously. Previously the request count would not have been updated until the request to the server is actually in flight. Now the request count is updated before the async interceptor is called.

The new behaviour is correct but it may change the expected behaviour in a small number of e2e test cases where an async request interceptor is being used.

$q due to:

Previously, throwing an error from a promise’s onFulfilled or onRejection handlers, would result in passing the error to the $exceptionHandler() (in addition to rejecting the promise with the error as reason).

Now, a thrown error is treated exactly the same as a regular rejection. This applies to all services/controllers/filters etc that rely on $q (including built-in services, such as $http and $route). For example, $http’s transformRequest/Response functions or a route’s redirectTo function as well as functions specified in a route’s resolve object, will no longer result in a call to $exceptionHandler() if they throw an error. Other than that, everything will continue to behave in the same way; i.e. the promises will be rejected, route transition will be cancelled, $routeChangeError events will be broadcasted etc.

Unhandled rejected promises will be logged to $exceptionHandler.

Tests that depend on specific order or number of messages in $exceptionHandler will need to handle rejected promises report.

ngTransclude due to:

Previously whitespace only transclusion would be treated as the transclusion being “not empty”, which meant that fallback content was not used in that case.

Now if you only provide whitespace as the transclusion content, it will be assumed to be empty and the fallback content will be used instead.

If you really do want whitespace then you can force it to be used by adding a comment to the whitespace.

ngModelOptions due to:

Previously, if a setting was not applied on ngModelOptions, then it would default to undefined. Now the setting will be inherited from the nearest ngModelOptions ancestor.

It is possible that an ngModelOptions directive that does not set a property, has an ancestor ngModelOptions that does set this property to a value other than undefined. This would cause the ngModel and input controls below this ngModelOptions directive to display different behaviour. This is fixed by explicitly setting the property in the ngModelOptions to prevent it from inheriting from the ancestor.

For example if you had the following HTML:

<form ng-model-options="{updateOn: 'blur'}">
  <input ng-model="..." ng-model-options="{allowInvalid: true}">
</form>

Then before this change the input would update on the default event not blur. After this change the input will inherit the option to update on blur. If you want the original behaviour then you will need to specify the option on the input as well:

<form ng-model-options="{updateOn: 'blur'}">
  <input ng-model="..." ng-model-options="{updateOn: 'default', allowInvalid: true}">
</form>

The programmatic API for ngModelOptions has changed. You must now read options via the getOption method, rather than accessing the option directly as a property of the options object. This does not affect the usage in templates and only affects custom directives that might have been reading options for their own purposes.

$compile due to:

Note: Everything described below affects IE11 only.

Previously, consecutive text nodes would not get merged if they had no parent. They will now, which might have unexpected side effects in the following cases:

  1. Passing an array or jqLite/jQuery collection of parent-less text nodes to $compile directly:

    // Assuming:
    var textNodes = [
      document.createTextNode('{{'),
      document.createTextNode('"foo:"'),
      document.createTextNode('}}')
    ];
    var compiledNodes = $compile(textNodes)($rootScope);
    
    // Before:
    console.log(compiledNodes.length);   // 3
    console.log(compiledNodes.text());   // {{'foo'}}
    
    // After:
    console.log(compiledNodes.length);   // 1
    console.log(compiledNodes.text());   // foo
    
    // To get the old behavior, compile each node separately:
    var textNodes = [
      document.createTextNode('{{'),
      document.createTextNode('"foo"'),
      document.createTextNode('}}')
    ];
    var compiledNodes = angular.element(textNodes.map(function (node) {
      return $compile(node)($rootScope)[0];
    }));
  2. Using multi-slot transclusion with non-consecutive, default-content text nodes (that form interpolated expressions when merged):

    // Assuming the following component:
    .component('someThing', {
      template: '<ng-transclude><!-- Default content goes here --></ng-transclude>'
      transclude: {
        ignored: 'veryImportantContent'
      }
    })
    <!-- And assuming the following view: -->
    <some-thing>
      {{
      <very-important-content>Nooot</very-important-content>
      'foo'}}
    </some-thing>
    
    <!-- Before: -->
    <some-thing>
      <ng-transclude>
        {{       <-- Two separate
        'foo'}}  <-- text nodes
      </ng-transclude>
    </some-thing>
    
    <!-- After: -->
    <some-thing>
      <ng-transclude>
        foo  <-- The text nodes were merged into `{{'foo'}}`, which was then interpolated
      </ng-transclude>
    </some-thing>
    
    <!-- To (visually) get the old behavior, wrap top-level text nodes on -->
    <!-- multi-slot transclusion directives into `<span>` elements; e.g.: -->
    <some-thing>
      <span>{{</span>
      <very-important-content>Nooot</very-important-content>
      <span>'foo'}}</span>
    </some-thing>
    
    <!-- Result: -->
    <some-thing>
      <ng-transclude>
        <span>{{</span>       <-- Two separate
        <span>'foo'}}</span>  <-- nodes
      </ng-transclude>
    </some-thing>

Using interpolation in any on* event attributes (e.g. <button onclick="{{myVar}}">) will now throw the “nodomevents” error at compile time. Previously the nodomevents was thrown at link time. The new behavior makes it consistent with the “selmulti” error. The breaking change should be rare, as it relates to incorrect API use that should not make it to production apps in the first place.

link[href] attributes are now protected via $sce, which prevents interpolated values that fail the RESOURCE_URL context tests from being used in interpolation.

For example if the application is running at https://docs.angularjs.org then the following will fail:

<link href="{{ 'http://mydomain.org/unsafe.css' }}" rel="stylesheet">

By default, RESOURCE_URL safe URLs are only allowed from the same domain and protocol as the application document.

To use URLs from other domains and/or protocols, you may either whitelist them or wrap it into a trusted value by calling $sce.trustAsResourceUrl(url).

White-space in attributes is no longer trimmed automatically. This includes leading and trailing white-space, and attributes that are purely white-space.

To migrate, attributes that require trimming must now be trimmed manually.

A common cases where stray white-space can cause problems is when attribute values are compared, for example in an $observer:

Before:

$attrs.$observe('myAttr', function(newVal) {
  if (newVal === 'false') ...
});

To migrate, the attribute value should be trimmed manually:

$attrs.$observe('myAttr', function(newVal) {
  if (newVal.trim() === 'false') ...
});

Note that $parse trims expressions automatically, so attributes with expressions (e.g. directive bindings) are unlikely to be affected by stray white-space.

ngRoute due to:

In cases where ngView was loaded asynchronously, $route (and its dependencies; e.g. $location) might also have been instantiated asynchronously. After this change, $route (and its dependencies) will - by default - be instantiated early on.

Although this is not expected to have unwanted side-effects in normal application behavior, it may affect your unit tests: When testing a module that (directly or indirectly) depends on ngRoute, a request will be made for the default route’s template. If not properly “trained”, $httpBackend will complain about this unexpected request.

You can restore the previous behavior (and avoid unexpected requests in tests), by using $routeProvider.eagerInstantiationEnabled(false).

The $route service no longer instantiates controllers nor calls resolves or template functions for routes that have a redirectTo unless the redirectTo is a function that returns undefined.

Previously, if redirectTo was a function that threw an Error, execution was aborted without firing a $routeChangeError event. Now, if a redirectTo function throws an Error, a $routeChangeError event will be fired.

ngMock due to:

Calling $httpBackend.verifyNoOutstandingRequest() will trigger a digest. This will ensure that requests fired asynchronously will also be detected (without the need to manually trigger a digest). This is not expected to affect the majority of test-suites. Most of the time, a digest is (directly or indirectly) triggered anyway, before calling verifyNoOutstandingRequest(). In the unlikely case that a test needs to verify the timing of a request with respect to the digest cycle, you should rely on other means, such as mocking and/or spying.

It is no longer valid to explicitly pass undefined as the url argument to any of the $httpBackend.when...() and $httpBackend.expect...() methods.

While this argument is optional, it must have a defined value if it is provided.

Previously passing an explicit undefined value was ignored but this lead to invalid tests passing unexpectedly.

ngAria due to:

If you were explicitly setting the value of the bindKeypress flag, you need to change your code to use bindKeydown instead.

Before: $ariaProvider.config({bindKeypress: xyz}) After: $ariaProvider.config({bindKeydown: xyz})

Note: If the element already has any of the ngKeydown/ngKeyup/ngKeypress directives, ngAria will not bind to the keydown event, since it assumes that the developer has already taken care of keyboard interaction for that element.

Although it is not expected to affect many applications, it might be desirable to keep the previous behavior of binding to the keypress event instead of the keydown. In that case, you need to manually use the ngKeypress directive (in addition to ngClick).

Before:

<div ng-click="onClick()">
  I respond to `click` and `keypress` (not `keydown`)
</div>

After:

<div ng-click="onClick()" ng-keypress="onClick()">
  I respond to `click` and `keypress` (not `keydown`)
</div>
<!-- OR -->
<div ng-click="onClick()">
  I respond to `click` and `keydown` (not `keypress`)
</div>

Finally, it is possible that this change affects your unit or end-to-end tests. If you are currently expecting your custom buttons to automatically respond to the keypress event (due to ngAria), you need to change the tests to trigger keydown events instead.

ngAria will no longer add the “role” attribute to native control elements (textarea, button, select, summary, details, a, and input). Previously, “role” was not added to input, but all others in the list.

This should not affect accessibility, because native inputs are accessible by default, but it might affect applications that relied on the “role” attribute being present (e.g. for styling or as directive attributes).

$resource due to:

All owned properties of the params object that are not used to replace URL params, will be passed to $http as config.params (to be used as query parameters in the URL), even if Object.prototype has a property with the same name. E.g.:

Before:

var Foo = $resource('/foo/:id');
Foo.get({id: 42, bar: 'baz', toString: 'hmm'});
    // URL: /foo/42?bar=baz
    // Note that `toString` is _not_ included in the query,
    // because `Object.prototype.toString` is defined :(

After:

var Foo = $resource('/foo/:id');
Foo.get({id: 42, bar: 'baz', toString: 'hmm'});
    // URL: /foo/42?bar=baz&toString=hmm
    // Note that `toString` _is_ included in the query, as expected :)

Although it shouldn’t matter in practice (since both the encoded and the unencoded ; character would be interpreted identically by the server), this change could break some tests: For example, where $httpBackend was set up to expect an encoded ; character, but the request is made to the URL with an unencoded ; character.

select due to:

<option> elements added to <select ng-model> via ngValue now add their values in hash form, i.e. <option ng-value="myString"> becomes <option ng-value="myString" value="string:myString">.

This is done to support binding options with values of any type to selects.

This should rarely affect applications, as the values of options are usually not relevant to the application logic, but it’s possible that option values are checked in tests.

Option elements will no longer set their value attribute from their text value when their select element has no ngModel associated. Setting the value is only needed for the select directive to match model values and options. If no ngModel is present, the select directive doesn’t need it.

This should not affect many applications as the behavior was undocumented and not part of a public API. It also has no effect on the usual HTML5 behavior that sets the select value to the option text if the option does not provide a value attribute.

ngBind due to:

ngBind now uses the same logic as $interpolate (i.e. {{myString}}) when binding, which means values other than strings are now transformed as following: - null / undefined become empty string - with an object’s custom toString() function, except if the object is a Date, Array, or Number - otherwise with JSON.stringify

Previously, ngBind would always use toString().

The following examples show the different output:

$scope.myPlainObject = {a: 1, b: 2};
$scope.myCustomObject = {a: 1, b: 2, toString: function() {return 'a+b';}};

Plain Object:

<!-- Before: -->
<span ng-bind="myPlainObject">[object Object]</span>

<!-- After: -->
<span ng-bind="myPlainObject">{'a':1,'b':2}</span>

Object with custom toString():

<!-- Before: -->
<span ng-bind="myCustomObject">[object Object]</span>

<!-- After: -->
<span ng-bind="myCustomObject">a+b</span>

If you want the output of toString(), you can use it directly on the value in ngBind:

<span ng-bind="myObject.toString()">[object Object]</span>

$interpolate due to:

When converting values to strings, interpolation now uses a custom toString() function on objects that are not Number, Array or Date (custom means that the toString function is not the same as Object.prototype.toString). Otherwise, interpolation uses JSON.stringify() as usual.

Should you have a custom toString() function but still want the output of JSON.stringify(), migrate as shown in the following examples:

Before:

<span>{{myObject}}</span>

After - use the json filter to stringify the object:

<span>{{myObject | json}}</span>

loader due to:

module.decorator declarations are now processed as part of the module.config queue and may result in providers being decorated in a different order if module.config blocks are also used to decorate providers via $provide.decorator.

For example, consider the following declaration order in which ‘theFactory’ is decorated by both a module.decorator and a $provide.decorator:

angular
  .module('theApp', [])
  .factory('theFactory', theFactoryFn)
  .config(function($provide) {
    $provide.decorator('theFactory', provideDecoratorFn);
  })
  .decorator('theFactory', moduleDecoratorFn);

Prior to this fix, ‘theFactory’ provider would be decorated in the following order: 1. moduleDecoratorFn 2. provideDecoratorFn

The result of this fix changes the order in which ‘theFactory’ is decorated because now module.decorator declarations are processed in the same order as module.config declarations: 1. provideDecoratorFn 2. moduleDecoratorFn

$location due to:

The hash-prefix for $location hash-bang URLs has changed from the empty string "" to the bang “!”. If your application does not use HTML5 mode or is being run on browsers that do not support HTML5 mode, and you have not specified your own hash-prefix then client side URLs will now contain a “!” prefix. For example, rather than mydomain.com/#/a/b/c will become mydomain.com/#!/a/b/c.

If you actually wanted to have no hash-prefix then you should configure this by adding a configuration block to you application:

appModule.config(['$locationProvider', function($locationProvider) {
  $locationProvider.hashPrefix('');
}]);

input[type=range] due to:

Due to the way that input[type=range] elements behave this feature modifies the behavior of such elements when bound to ngModel:

input[type=number] due to:

Number inputs that use ngModel and specify a step constraint (via step/ngStep attributes) will now have a new validator (step), which will verify that the current value is valid under the step constraint (according to the spec). Previously, the step constraint was ignored by ngModel, treating values as valid even when there was a step-mismatch.

If you want to restore the previous behavior (use the step attribute while disabling step validation), you can overwrite the built-in step validator with a custom directive. For example:

// For all `input` elements...
.directive('input', function() {
  return {
    restrict: 'E',
    require: '?ngModel',
    link: function (scope, elem, attrs, ngModelCtrl) {
      // ...that are of type "number" and have `ngModel`...
      if ((attrs.type === 'number') && ngModelCtrl) {
        // ...remove the `step` validator.
        delete ngModelCtrl.$validators.step;
      }
    }
  };
})

# 1.2.32 alternation-intention (2016-10-11)

This release reverts the fix in 1.2.31 and provides an alternative fix that doesn’t break Angular Material.

Reverts

Bug Fixes

# 1.4.13 croaking-elderweed (2016-10-10)

Bug Fixes

# 1.2.31 barking-moustache (2016-10-10)

Bug Fixes

# 1.4.12

Invalid release

# 1.5.8 arbitrary-fallbacks (2016-07-22)

Bug Fixes

Features

Performance Improvements

# 1.2.30 patronal-resurrection (2016-07-21)

Note: This release contains some security fixes that required breaking changes. Since the legacy 1.2.x branch is the only version branch that supports IE8, it was necessary to introduce a couple of low-impact breaking changes in a patch release - something we generally avoid - in order to make the fixes available to people that still need IE8 support.

Bug Fixes

Breaking Changes

link[href] attributes are now protected via $sce, which prevents interpolated values that fail the RESOURCE_URL context tests from being used in interpolation. For example if the application is running at https://mydomain.org/ then the following will fail:

<link rel="stylesheet" href="{{ 'https://otherdomain.org/unsafe.css' }}" />

By default, RESOURCE_URL safe URLs are only allowed from the same domain and protocol as the application document. To use URLs from other domains and/or protocols, you may either whitelist them using $sceDelegateProvider.resourceUrlWhitelist(...) or wrap them into a trusted value by calling $sce.trustAsResourceUrl(url).

The $sanitize service will now remove instances of the usemap attribute from any elements passed to it.

This attribute is used to reference another element by name or id. Since the name and id attributes are already blacklisted, a sanitized usemap attribute could only reference unsanitized content, which is a security risk.

# 1.5.7 hexagonal-circumvolution (2016-06-15)

Bug Fixes

Features

# 1.4.12 cultural-conservation (2016-06-15)

This release contains only documentation updates. Specifically, it restores the old (deprecated) version of the tutorial on the 1.4.x branch. If someone needs a version of the tutorial that is compatible with v1.4, they can find it at https://code.angularjs.org/1.4.12/docs/tutorial/.

As always, the latest and greatest version of the tutorial can be found on the master branch (at https://docs.angularjs.org/tutorial/). We strongly recommend using this version as it is kept up-to-date, showcases several new features introduced in v1.5 or later and follows modern best practices.

# 1.5.6 arrow-stringification (2016-05-27)

Bug Fixes

Features

Performance Improvements

# 1.4.11 relentless-syncomania (2016-05-27)

Bug Fixes

Performance Improvements

# 1.5.5 material-conspiration (2016-04-18)

Reverts

Bug Fixes

Features

Performance Improvements

# 1.5.4 graduated-sophistry (2016-04-14)

This was a partially published release that you should ignore.

# 1.5.3 diplohaplontic-meiosis (2016-03-25)

Bug Fixes

Features

# 1.5.2 differential-recovery (2016-03-18)

This release reverts a breaking change that accidentally made it into the 1.5.1 release. See fee7bac3 for more info.

Bug Fixes

# 1.5.1 equivocal-sophistication (2016-03-16)

Bug Fixes

Features

Performance Improvements

# 1.4.10 benignant-oscillation (2016-03-16)

Bug Fixes

Features

Performance Improvements

# 1.5.0 ennoblement-facilitation (2016-02-05)

Bug Fixes

Features

Breaking Changes

Upgrade to 1.5.1

This version of AngularJS is problematic due to a issue during its release. Please upgrade to version 1.5.2.

# 1.5.0-rc.2 controller-requisition (2016-01-28)

Deprecation Warning

Bug Fixes

Features

Performance Improvements

Breaking Changes

The $sanitize service will now remove instances of the usemap attribute from any elements passed to it.

This attribute is used to reference another element by name or id. Since the name and id attributes are already blacklisted, a sanitized usemap attribute could only reference unsanitized content, which is a security risk.

The ngClick override directive from the ngTouch module is deprecated and disabled by default. This means that on touch-based devices, users might now experience a 300ms delay before a click event is fired.

If you rely on this directive, you can still enable it with the $touchProvider.ngClickOverrideEnabled()method:

angular.module('myApp').config(function($touchProvider) {
  $touchProvider.ngClickOverrideEnabled(true);
});

Going forward, we recommend using FastClick or perhaps one of the Angular 3rd party touch-related modules that provide similar functionality.

Also note that modern browsers already remove the 300ms delay under some circumstances: - Chrome and Firefox for Android remove the 300ms delay when the well-known <meta name="viewport" content="width=device-width"> is set - Internet Explorer removes the delay when touch-action css property is set to none or manipulation - Since iOs 8, Safari removes the delay on so-called “slow taps”

See this article by Telerik for more info on the topic.

Note that this change does not affect the ngSwipe directive.

# 1.4.9 implicit-superannuation (2016-01-21)

Bug Fixes

Minor Features

Performance Improvements

Breaking Changes

While we do not deem the following to be a real breaking change we are highlighting it here in the changelog to ensure that it does not surprise anyone.

Possible breaking change for users who updated their code to provide a timeout promise for a $resource request in version v1.4.8.

Up to v1.4.7 (included), using a promise as a timeout in $resource, would silently fail (i.e. have no effect).

In v1.4.8, using a promise as timeout would have the (buggy) behaviour described in https://github.com/angular/angular.js/pull/12657#issuecomment-152108887. (I.e. it will work as expected for the first time you resolve the promise and will cancel all subsequent requests after that - one has to re-create the resource class. This was not documented.)

With this change, using a promise as timeout in v1.4.9 onwards is not allowed. It will log a warning and ignore the timeout value.

If you need support for cancellable $resource actions, you should upgrade to version 1.5 or higher.

# 1.5.0-rc.1 quantum-fermentation (2016-01-15)

Features

Bug Fixes

Breaking Changes

Before this change, the filter assumed that the input (if not undefined/null) was of type ‘string’ and that certain methods (such as .match()) would be available on it. Passing a non-string value would most likely result in a not-very-useful error being thrown (trying to call a method that does not exist) or in unexpected behavior (if the input happened to have the assumed methods).

After this change, a proper (informative) error will be thrown. If you want to pass non-string values through linky, you need to explicitly convert them to strings first. Since input values could be initialized asynchronously, undefined or null will still be returned unchanged (without throwing an error).

# 1.5.0-rc.0 oblong-panoptikum (2015-12-09)

This is the first Release Candidate for AngularJS 1.5.0. Please try upgrading your applications and report any regressions or other issues you find as soon as possible.

Features

Bug Fixes

Breaking Changes

This is only a breaking change to a feature that was added in beta 2. If you have not started using multi-slot transclusion then this will not affect you.

The keys and values for the transclude map of the directive definition have been swapped around to be more consistent with the other maps, such as scope and bindToController.

Now the key is the slot name and the value is a normalized element selector.

Using a promise as timeout is no longer supported and will log a warning. It never worked the way it was supposed to anyway.

Before:

var deferred = $q.defer();
var User = $resource('/api/user/:id', {id: '@id'}, {
  get: {method: 'GET', timeout: deferred.promise}
});

var user = User.get({id: 1});   // sends a request
deferred.resolve();             // aborts the request

// Now, we need to re-define `User` passing a new promise as `timeout`
// or else all subsequent requests from `someAction` will be aborted
User = $resource(...);
user = User.get({id: 2});

After:

var User = $resource('/api/user/:id', {id: '@id'}, {
  get: {method: 'GET', cancellable: true}
});

var user = User.get({id: 1});   // sends a request
user.$cancelRequest();      // aborts the request

user = User.get({id: 2});

The $sanitize service will now remove instances of the <use> tag from the content passed to it.

This element is used to import external SVG resources, which is a security risk as the $sanitize service does not have access to the resource in order to sanitize it.

A new property to access route resolves is now available on the scope of the route. The default name for this property is $resolve. If your scope already contains a property with this name then it will be hidden or overwritten.

In this case, you should choose a custom name for this property, that does not collide with other properties on the scope, by specifying the resolveAs property on the route.

A new property to access all the locals for an expression is now available on the scope. This property is $locals.

# 1.4.8 ice-manipulation (2015-11-19)

Bug Fixes

Performance Improvements

# 1.5.0-beta.2 effective-delegation (2015-11-17)

Bug Fixes

Features

Performance Improvements

Breaking Changes

ngMessage is now compiled with a priority of 1, which means directives on the same element as ngMessage with a priority lower than 1 will be applied when ngMessage calls the $transclude function. Previously, they were applied during the initial compile phase and were passed the comment element created by the transclusion of ngMessage. To restore this behavior, custom directives need to have their priority increased to at least “1”.

Previously, an non array-like input would pass through the orderBy filter unchanged. Now, an error is thrown. This can be worked around by converting an object to an array, either manually or using a filter such as https://github.com/petebacondarwin/angular-toArrayFilter. (null and undefined still pass through without an error, in order to support asynchronous loading of resources.)

# 1.5.0-beta.1 dense-dispersion (2015-09-29)

Bug Fixes

Features

Performance Improvements

Breaking Changes

Applications that depend on this option can use to turn the option back on, but while doing so, please read the warning provided in the documentation for information on preventing click-hijacking attacks when this option is turned on.

If your data contains falsy values ('', 0, false and null) for option groups, then these options will now be placed into option groups. Previously all of these falsy values were treated as the option not being a member of a group.

Only option groups that are undefined will result in the option being put in no group. If you have data that contains falsy values that should not be used as groups then you must filter the values before passing them to ngOptions converting falsy values to undefined.

ngOptions will now throw if ngModel is not present on the select element. Previously, having no ngModel let ngOptions silently fail, which could lead to hard to debug errors. The change should therefore not affect any applications, as it simply makes the requirement more strict and alerts the developer explicitly.

# 1.4.7 dark-luminescence (2015-09-29)

Bug Fixes

Features

# 1.3.20 shallow-translucence (2015-09-29)

Bug Fixes

# 1.2.29 ultimate-deprecation (2015-09-29)

Bug Fixes

1.5.0-beta.0 intialization-processation (2015-09-17)

Bug Fixes

# 1.4.6 multiplicative-elevation (2015-09-17)

Bug Fixes

Performance Improvements

# 1.3.19 glutinous-shriek (2015-09-15)

Bug Fixes

Features

Possible Breaking Changes

The ngPattern and pattern directives will validate the regex against the viewValue of ngModel, i.e. the value of the model before the $parsers are applied. Previously, the modelValue (the result of the $parsers) was validated.

This fixes issues where input[date] and input[number] cannot be validated because the viewValue string is parsed into Date and Number respectively (starting with AngularJS 1.3). It also brings the directives in line with HTML5 constraint validation, which validates against the input value.

This change is unlikely to cause applications to fail, because even in AngularJS 1.2, the value that was validated by pattern could have been manipulated by the $parsers, as all validation was done inside this pipeline.

If you rely on the pattern being validated against the modelValue, you must create your own validator directive that overwrites the built-in pattern validator:

.directive('patternModelOverwrite', function patternModelOverwriteDirective() {
  return {
    restrict: 'A',
    require: '?ngModel',
    priority: 1,
    compile: function() {
      var regexp, patternExp;

      return {
        pre: function(scope, elm, attr, ctrl) {
          if (!ctrl) return;

          attr.$observe('pattern', function(regex) {
            /**
             * The built-in directive will call our overwritten validator
             * (see below). We just need to update the regex.
             * The preLink fn guarantees our observer is called first.
             */
            if (isString(regex) && regex.length > 0) {
              regex = new RegExp('^' + regex + '$');
            }

            if (regex && !regex.test) {
              //The built-in validator will throw at this point
              return;
            }

            regexp = regex || undefined;
          });

        },
        post: function(scope, elm, attr, ctrl) {
          if (!ctrl) return;

          regexp, patternExp = attr.ngPattern || attr.pattern;

          //The postLink fn guarantees we overwrite the built-in pattern validator
          ctrl.$validators.pattern = function(value) {
            return ctrl.$isEmpty(value) ||
              isUndefined(regexp) ||
              regexp.test(value);
          };
        }
      };
    }
  };
});

# 1.4.5 permanent-internship (2015-08-28)

Bug Fixes

Breaking Changes

The ngPattern and pattern directives will validate the regex against the viewValue of ngModel, i.e. the value of the model before the $parsers are applied. Previously, the modelValue (the result of the $parsers) was validated.

This fixes issues where input[date] and input[number] cannot be validated because the viewValue string is parsed into Date and Number respectively (starting with AngularJS 1.3). It also brings the directives in line with HTML5 constraint validation, which validates against the input value.

This change is unlikely to cause applications to fail, because even in AngularJS 1.2, the value that was validated by pattern could have been manipulated by the $parsers, as all validation was done inside this pipeline.

If you rely on the pattern being validated against the modelValue, you must create your own validator directive that overwrites the built-in pattern validator:

.directive('patternModelOverwrite', function patternModelOverwriteDirective() {
  return {
    restrict: 'A',
    require: '?ngModel',
    priority: 1,
    compile: function() {
      var regexp, patternExp;

      return {
        pre: function(scope, elm, attr, ctrl) {
          if (!ctrl) return;

          attr.$observe('pattern', function(regex) {
            /**
             * The built-in directive will call our overwritten validator
             * (see below). We just need to update the regex.
             * The preLink fn guarantees our observer is called first.
             */
            if (isString(regex) && regex.length > 0) {
              regex = new RegExp('^' + regex + '$');
            }

            if (regex && !regex.test) {
              //The built-in validator will throw at this point
              return;
            }

            regexp = regex || undefined;
          });

        },
        post: function(scope, elm, attr, ctrl) {
          if (!ctrl) return;

          regexp, patternExp = attr.ngPattern || attr.pattern;

          //The postLink fn guarantees we overwrite the built-in pattern validator
          ctrl.$validators.pattern = function(value) {
            return ctrl.$isEmpty(value) ||
              isUndefined(regexp) ||
              regexp.test(value);
          };
        }
      };
    }
  };
});

# 1.3.18 collective-penmanship (2015-08-18)

Bug Fixes

# 1.4.4 pylon-requirement (2015-08-13)

Bug Fixes

Features

Performance Improvements

Breaking Changes

The previous behavior involved ngAnimate having to wait for one requestAnimationFrame before CSS classes were added/removed. The CSS classes are now applied directly after the first digest that is triggered after $animate.addClass, $animate.removeClass or $animate.setClass is called. If any of your code relies on waiting for one frame before checking for CSS classes on the element then please change this behavior. If a parent class-based animation, however, is run through a JavaScript animation which triggers an animation for beforeAddClass and/or beforeRemoveClass then the CSS classes will not be applied in time for the children (and the parent class-based animation will not be cancelled by any child animations).

The previous behavior involved creating an extra promise that needed to be resolved. This is no longer needed when $q.when is called with a value. In the case that the test is not aware if $q.when is called with a value or another promise, it is possible to replace $timeout.flush(); with $timeout.flush(0);.

describe('$q.when', function() {
  it('should not need a call to $timeout.flush() to resolve already resolved promises',
      inject(function($q, $timeout) {
    $q.when('foo');
    // In AngularJS 1.4.3 a call to `$timeout.flush();` was needed
    $timeout.verifyNoPendingTasks();
  }));

  it('should accept $timeout.flush(0) when not sure if $q.when was called with a value or a promise',
      inject(function($q, $timeout) {
    $q.when('foo');
    $timeout.flush(0);
    $timeout.verifyNoPendingTasks();
  }));

  it('should need a call to $timeout.flush() to resolve $q.when when called with a promise',
        inject(function($q, $timeout) {
    $q.when($q.when('foo'));
    $timeout.flush();
    $timeout.verifyNoPendingTasks();
  }));
});

# 1.4.3 foam-acceleration (2015-07-15)

Bug Fixes

# 1.4.2 nebular-readjustment (2015-07-06)

Bug Fixes

Features

Breaking Changes

Before:

<div ng-include="findTemplate('https://example.com/myTemplate.html')"></div>
$scope.findTemplate = function(templateName) {
  return $sce.trustAsResourceUrl(templateName);
};

To migrate, either cache the result of trustAsResourceUrl(), or put the template url in the resource whitelist in the config() function:

After:

var templateCache = {};
$scope.findTemplate = function(templateName) {
  if (!templateCache[templateName]) {
    templateCache[templateName] = $sce.trustAsResourceUrl(templateName);
  }

  return  templateCache[templateName];
};

// Alternatively, use `$sceDelegateProvider.resourceUrlWhitelist()`:

angular.module('myApp', []).config(function($sceDelegateProvider) {
  $sceDelegateProvider.resourceUrlWhitelist(['self', 'https://example.com/**'])
});

# 1.3.17 tsktskskly-euouae (2015-07-06)

Bug Fixes

# 1.4.1 hyperionic-illumination (2015-06-16)

Bug Fixes

Features

Performance Improvements

# 1.3.16 cookie-oatmealification (2015-06-05)

Bug Fixes

Features

# 1.4.0 jaracimrman-existence (2015-05-26)

Bug Fixes

Features

# 1.4.0-rc.2 rocket-zambonimation (2015-05-12)

Bug Fixes

Features

Breaking Changes

// before
var animator = $animateCss(element, { ... });
if (!animator) {
  continueApp();
  return;
}
var runner = animator.start();
runner.done(continueApp);
runner.then(continueApp);

// now
var animator = $animateCss(element, { ... });
var runner = animator.start();
runner.done(continueApp);
runner.then(continueApp);

Instead just use the ng-anchor CSS class like so:

<div class="container-animation" ng-if="on">
   <div ng-animate-ref="1" class="my-anchor-element"></div>
</div>

<div class="container-animation" ng-if="!on">
   <div ng-animate-ref="1" class="my-anchor-element"></div>
</div>

before:

/* before (notice the container-animation CSS class) */
.container-animation-anchor {
  transition:0.5s linear all;
}

now:

/* now (just use `ng-anchor` on a class that both the
   elements that contain `ng-animate-ref` share) */
.my-anchor-element.ng-anchor {
  transition:0.5s linear all;
}

So don’t do this:

// only animate elements that contain the `ng-animate` CSS class
$animateProvider.classNameFilter(/ng-animate/);

// or partially contain it
$animateProvider.classNameFilter(/some-class ng-animate another-class/);

but this is OK:

$animateProvider.classNameFilter(/ng-animate-special/);

Although it is unlikely that anyone is using it in this way, this change does change the behavior of ngOptions in the following case:

In this case these properties with non-numeric keys will be ignored.

** Here array-like is defined by the result of a call to this internal function: https://github.com/angular/angular.js/blob/v1.4.0-rc.1/src/Angular.js#L198-L211 **

To get the desired behavior you need to iterate using the object form of the ngOptions syntax (value.label for (key, value) in items)`).

# v1.4.0-rc.1 sartorial-chronography (2015-04-24)

Bug Fixes

Features

# v1.4.0-rc.0 smooth-unwinding (2015-04-10)

Bug Fixes

Features

Performance Improvements

Breaking Changes

// < 1.4
$animate.enabled(false, element);

// 1.4+
$animate.enabled(element, false);
// < 1.4
element.on('$animate:before', function(e, data) {
  if (data.event === 'enter') { ... }
});
element.off('$animate:before', fn);

// 1.4+
$animate.on(element, 'enter', function(data) {
  //...
});
$animate.off(element, 'enter', fn);
// < 1.4
$animate.enter(element).then(function() {
  $scope.$apply(function() {
    $scope.explode = true;
  });
});

// 1.4+
$animate.enter(element).then(function() {
  $scope.explode = true;
});

# 1.4.0-beta.6 cookie-liberation (2015-03-17)

Bug Fixes

Features

Breaking Changes

$cookies no longer exposes properties that represent the current browser cookie values. Now you must explicitly the methods described above to access the cookie values. This also means that you can no longer watch the $cookies properties for changes to the browser’s cookies.

This feature is generally only needed if a 3rd party library was programmatically changing the cookies at runtime. If you rely on this then you must either write code that can react to the 3rd party library making the changes to cookies or implement your own polling mechanism.

# 1.3.15 locality-filtration (2015-03-17)

Bug Fixes

Features

# 1.4.0-beta.5 karmic-stabilization (2015-02-24)

Bug Fixes

Features

Performance Improvements

Breaking Changes

The ngMessagesInclude attribute is now its own directive and that must be placed as a child element within the element with the ngMessages directive. (Keep in mind that the former behavior of the ngMessageInclude attribute was that all included ngMessage template code was placed at the bottom of the element containing the ngMessages directive; therefore to make this behave in the same way, place the element containing the ngMessagesInclude directive at the end of the container containing the ngMessages directive).

<!-- AngularJS 1.3.x -->
<div ng-messages="model.$error" ng-messages-include="remote.html">
  <div ng-message="required">Your message is required</div>
</div>

<!-- AngularJS 1.4.x -->
<div ng-messages="model.$error">
  <div ng-message="required">Your message is required</div>
  <div ng-messages-include="remote.html"></div>
</div>

it is no longer possible to use interpolation inside the ngMessages attribute expression. This technique is generally not recommended, and can easily break when a directive implementation changes. In cases where a simple expression is not possible, you can delegate accessing the object to a function:

<div ng-messages="ctrl.form['field_{{$index}}'].$error">...</div>

would become

<div ng-messages="ctrl.getMessages($index)">...</div>

where ctrl.getMessages()

ctrl.getMessages = function($index) {
  return ctrl.form['field_' + $index].$error;
}

transformRequest functions can no longer modify request headers.

Before this commit transformRequest could modify request headers, ex.:

function requestTransform(data, headers) {
    headers = angular.extend(headers(), {
      'X-MY_HEADER': 'abcd'
    });
  }
  return angular.toJson(data);
}

This behavior was unintended and undocumented, so the change should affect very few applications. If one needs to dynamically add / remove headers it should be done in a header function, for example:

$http.get(url, {
  headers: {
    'X-MY_HEADER': function(config) {
      return 'abcd'; //you've got access to a request config object to specify header value dynamically
    }
  }
})

# 1.3.14 instantaneous-browserification (2015-02-24)

Features

Bug Fixes

# 1.4.0-beta.4 overlyexplosive-poprocks (2015-02-09)

Bug Fixes

Features

# 1.3.13 meticulous-riffleshuffle (2015-02-09)

Bug Fixes

# 1.4.0-beta.3 substance-mimicry (2015-02-02)

Bug Fixes

Features

Performance Improvements

Breaking Changes

# 1.3.12 outlandish-knitting (2015-02-02)

Bug Fixes

Features

# 1.4.0-beta.2 holographic-rooster (2015-01-26)

Bug Fixes

Breaking Changes

Closes #9992 Closes #10352

# 1.3.11 spiffy-manatee (2015-01-26)

Bug Fixes

# 1.4.0-beta.1 trepidatious-salamander (2015-01-20)

Bug Fixes

Features

Breaking Changes

Previously, the order of items when using ngRepeat to iterate over object properties was guaranteed to be consistent by sorting the keys into alphabetic order.

Now, the order of the items is browser dependent based on the order returned from iterating over the object using the for key in obj syntax.

It seems that browsers generally follow the strategy of providing keys in the order in which they were defined, although there are exceptions when keys are deleted and reinstated. See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/delete#Cross-browser_issues

The best approach is to convert Objects into Arrays by a filter such as https://github.com/petebacondarwin/angular-toArrayFilter or some other mechanism, and then sort them manually in the order you need.

Closes #6210 Closes #10538

# 1.3.10 heliotropic-sundial (2015-01-20)

Bug Fixes

# 1.4.0-beta.0 photonic-umbrakinesis (2015-01-13)

Bug Fixes

Features

Performance Improvements

Breaking Changes

When using ngOptions: the directive applies a surrogate key as the value of the <option> element. This commit changes the actual string used as the surrogate key. We now store a string that is computed by calling hashKey on the item in the options collection; previously it was the index or key of the item in the collection.

(This is in keeping with the way that the unknown option value is represented in the select directive.)

Before you might have seen:

<select ng-model="x" ng-option="i in items">
  <option value="1">a</option>
  <option value="2">b</option>
  <option value="3">c</option>
  <option value="4">d</option>
</select>

Now it will be something like:

<select ng-model="x" ng-option="i in items">
  <option value="string:a">a</option>
  <option value="string:b">b</option>
  <option value="string:c">c</option>
  <option value="string:d">d</option>
</select>

If your application code relied on this value, which it shouldn’t, then you will need to modify your application to accommodate this. You may find that you can use the track by feature of ngOptions as this provides the ability to specify the key that is stored.

When iterating over an object’s properties using the (key, value) in obj syntax the order of the elements used to be sorted alphabetically. This was an artificial attempt to create a deterministic ordering since browsers don’t guarantee the order. But in practice this is not what people want and so this change iterates over properties in the order they are returned by Object.keys(obj), which is almost always the order in which the properties were defined.

setting the ngOptions attribute expression after the element is compiled, will no longer trigger the ngOptions behavior. This worked previously because the ngOptions logic was part of the select directive, while it is now implemented in the ngOptions directive itself.

the select directive will now use strict comparison of the ngModel scope value against option values to determine which option is selected. This means Number scope values will not be matched against numeric option strings. In AngularJS 1.3.x, setting scope.x = 200 would select the option with the value 200 in the following select:

<select ng-model="x">
  <option value="100">100</option>
  <option value="200">200</option>
</select>

In AngularJS 1.4.x, the ‘unknown option’ will be selected. To remedy this, you can simply initialize the model as a string: scope.x = '200', or if you want to keep the model as a Number, you can do the conversion via $formatters and $parsers on ngModel:

ngModelCtrl.$parsers.push(function(value) {
  return parseInt(value, 10); // Convert option value to number
});

ngModelCtrl.$formatters.push(function(value) {
  return value.toString(); // Convert scope value to string
});

# 1.3.9 multidimensional-awareness (2015-01-13)

Bug Fixes

Features

Performance Improvements

# 1.3.8 prophetic-narwhal (2014-12-19)

Bug Fixes

Performance Improvements

# 1.3.7 leaky-obstruction (2014-12-15)

Bug Fixes

Features

Performance Improvements

Breaking Changes

Previously, if either value being compared in the orderBy comparator was null or undefined, the order would, incorrectly, not change. Now, this order behaves more like Array.prototype.sort, which by default pushes null behind objects, due to n occurring after [ (the first characters of their stringified forms) in ASCII / Unicode. If toString is customized, or does not exist, the behavior is undefined.

# 1.2.28 finnish-disembarkation (2014-12-15)

Bug Fixes

# 1.3.6 robofunky-danceblaster (2014-12-08)

Bug Fixes

Features

Breaking Changes

We no longer throw an ihshprfx error if the URL after the base path contains only a hash fragment. Previously, if the base URL was http://abc.com/base/ and the hashPrefix is ! then trying to parse http://abc.com/base/#some-fragment would have thrown an error. Now we simply assume it is a normal fragment and that the path is empty, resulting $location.absUrl() === "http://abc.com/base/#!/#some-fragment".

This should not break any applications, but you can no longer rely on receiving the ihshprfx error for paths that have the syntax above. It is actually more similar to what currently happens for invalid extra paths anyway: If the base URL and hashPrfix are set up as above, then http://abc.com/base/other/path does not throw an error but just ignores the extra path: http://abc.com/base.

# 1.3.5 cybernetic-mercantilism (2014-12-01)

Bug Fixes

# 1.3.4 highfalutin-petroglyph (2014-11-24)

Bug Fixes

Features

Performance Improvements

Breaking Changes

For example:

<input ng-model="model.value" ng-model-options="{ getterSetter: true }">

would previously invoke model.value() in the global context.

Now, ngModel invokes value with model as the context.

It’s unlikely that real apps relied on this behavior. If they did they can use .bind to explicitly bind a getter/getter to the global context, or just reference globals normally without this.

# 1.2.27 prime-factorization (2014-11-20)

Bug Fixes

Performance Improvements

# 1.3.3 undersea-arithmetic (2014-11-17)

Bug Fixes

Features

Performance Improvements

Breaking Changes

# 1.3.2 cardiovasculatory-magnification (2014-11-07)

Bug Fixes

Features

Security Note

This release also contains security fixes for expression sandbox bypasses.

These issues affect only applications with known server-side XSS holes that are also using CSP to secure their client-side code. If your application falls into this rare category, we recommend updating your version of Angular.

We’d like to thank security researches Sebastian Lekies, Jann Horn, and Gábor Molnár for reporting these issues to us.

We also added a documentation page focused on security, which contains some of the best practices, DOs and DON’Ts. Please check out https://docs.angularjs.org/guide/security.

# 1.3.1 spectral-lobster (2014-10-31)

Bug Fixes

Features

Breaking Changes

<my-dir></my-dir>
// link function for directive myDir
link: function(scope, element, attr) {
  attr.$observe('myAttr', function(newVal) {
    scope.myValue = newVal ? newVal : 'myDefaultValue';
  })
}

Instead, check if the attribute is set before registering the observer:

link: function(scope, element, attr) {
  if (attr.myAttr) {
    // register the observer
  } else {
    // set the default
  }
}

# 1.3.0 superluminal-nudge (2014-10-13)

Bug Fixes

Features

Breaking Changes

# 1.3.0-rc.5 impossible-choreography (2014-10-08)

Bug Fixes

Features

Performance Improvements

Breaking Changes

If a template contains directives within comment nodes, and there is more than a single node in the template, those comment nodes are removed. The impact of this breaking change is expected to be quite low.

Closes #9212 Closes #9215

The $animate CSS class API will always defer changes until the end of the next digest. This allows ngAnimate to coalesce class changes which occur over a short period of time into 1 or 2 DOM writes, rather than many. This prevents jank in browsers such as IE, and is generally a good thing.

If you find that your classes are not being immediately applied, be sure to invoke $digest().

Closes #8234 Closes #9263

ngOptions will now throw an error when the comprehension expressions contains both a select as and track by expression.

These expressions are fundamentally incompatible because it is not possible to reliably and consistently determine the parent object of a model, since select as can assign any child of a value as the model value.

Prior to refactorings in this release, neither of these expressions worked correctly independently, and did not work at all when combined.

See #6564

Order of events has changed. Previously: $locationChangeStart -> $locationChangeSuccess -> $routeChangeStart -> $routeChangeSuccess

Now: $locationChangeStart -> $routeChangeStart -> $locationChangeSuccess -> -> $routeChangeSuccess

Fixes #5581 Closes #5714 Closes #9502

# 1.3.0-rc.4 unicorn-hydrafication (2014-10-01)

Bug Fixes

Features

Performance Improvements

Breaking Changes

$transclude functions no longer attach $destroy event handlers to the transcluded content, and so the associated transclude scope will not automatically be destroyed if you remove a transcluded element from the DOM using direct DOM manipulation such as the jquery remove() method.

If you want to explicitly remove DOM elements inside your directive that have been compiled, and so potentially contain child (and transcluded) scopes, then it is your responsibility to get hold of the scope and destroy it at the same time.

The suggested approach is to create a new child scope of your own around any DOM elements that you wish to manipulate in this way and destroy those scopes if you remove their contents - any child scopes will then be destroyed and cleaned up automatically.

Note that all the built-in directives that manipulate the DOM (ngIf, ngRepeat, ngSwitch, etc) already follow this best practice, so if you only use these for manipulating the DOM then you do not have to worry about this change.

Closes #9095 Closes #9281

Closes #9105

(Note: this change landed in 1.3.0-rc.3, but was not considered a breaking change at the time).

For text based inputs (text, email, url), the $viewValue will now always be converted to a string, regardless of what type the value is on the model.

To migrate, any code or expressions that expect the $viewValue to be anything other than string should be updated to expect a string.

Similar to input[number] Angular will now throw if the model value for a input[date] is not a Date object. Previously, Angular only showed an empty string instead. Angular does not set validation errors on the <input> in this case as those errors are shown to the user, but the erroneous state was caused by incorrect application logic and not by the user.

# 1.2.26 captivating-disinterest (2014-10-01)

Bug Fixes

# 1.3.0-rc.3 aggressive-pacification (2014-09-23)

Bug Fixes

Features

Performance Improvements

Breaking Changes

Fixes #8934

# 1.2.25 hypnotic-gesticulation (2014-09-16)

Bug Fixes

# 1.3.0-rc.2 tactile-perception (2014-09-16)

Bug Fixes

Features

Performance Improvements

Breaking Changes

Previously it was just a good practice to make all filters stateless. Now it’s a requirement in order for the model change-observation to pick up all changes.

If an existing filter is stateful, it can be flagged as such but keep in mind that this will result in a significant performance-penalty (or rather lost opportunity to benefit from a major perf improvement) that will affect the $digest duration.

To flag a filter as stateful do the following:

myApp.filter('myFilter', function() {
  function myFilter(input) { ... };
  myFilter.$stateful = true;
  return myFilter;
});

# 1.3.0-rc.1 backyard-atomicity (2014-09-09)

Bug Fixes

Features

Performance Improvements

Breaking Changes

Closes #8941- ngSwitch: due to 0f806d96,

Ever since 0df93fd, tagged in v1.0.0rc1, the ngSwitch directive has had an undocumented change attribute, used for evaluating a scope expression when the switch value changes.

While it’s unlikely, applications which may be using this feature should work around the removal by adding a custom directive which will perform the eval instead. Directive controllers are re-instantiated when being transcluded, so by putting the attribute on each item that you want to be notified of a change to, you can more or less emulate the old behavior.

Example:

angular.module("switchChangeWorkaround", []).
  directive("onSwitchChanged", function() {
    return {
      link: function($scope, $element, $attrs) {
        $scope.$parent.$eval($attrs.onSwitchChanged);
      }
    };
  });
<div ng-switch="switcher">
  <div ng-switch-when="a" on-switch-changed="doSomethingInParentScope()"></div>
  <div ng-switch-when="b" on-switch-changed="doSomethingInParentScope()"></div>
</div>

Closes #8858 Closes #8822

# 1.2.24 static-levitation (2014-09-09)

Bug Fixes

Breaking Changes

The blur and focus event fire synchronously, also during DOM operations that remove elements. This lead to errors as the Angular model was not in a consistent state. See this fiddle for a demo.

This change executes the expression of those events using scope.$evalAsync if an $apply is in progress, otherwise keeps the old behavior.

Fixes #4979 Fixes #5945 Closes #8803 Closes #6910 Closes #5402

# 1.3.0-RC.0 sonic-boltification (2014-08-29)

Bug Fixes

Features

Performance Improvements

Breaking Changes

since 1.2.0 and 1.3.0-beta.1

Angular now requires a <base> tag when html5 mode of $location is enabled. Reasoning: Using html5 mode without a <base href="..."> tag makes relative links for images, links, … relative to the current url if the browser supports the history API. However, if the browser does not support the history API Angular falls back to using the #, and then all those relative links would be broken.

The <base> tag is also needed when a deep url is loaded from the server, e.g. http://server/some/page/url. In that case, Angular needs to decide which part of the url is the base of the application, and which part is path inside of the application.

To summarize: Now all relative links are always relative to the <base> tag.

Exception (also a breaking change): Link tags whose href attribute starts with a # will only change the hash of the url, but nothing else (e.g. <a href="#someAnchor">). This is to make it easy to scroll to anchors inside a document.

Related to #6162 Closes #8492

since 1.2.17 and 1.3.0-beta.10

In html5 mode without a <base> tag on older browser that don’t support the history API relative paths were adding up. E.g. clicking on <a href="page1"> and then on <a href="page2"> would produce $location.path()==='/page1/page2'. The code that introduced this behavior was removed and Angular now also requires a <base> tag to be present when using html5 mode.

Closes #8172, #8233

Angular will now throw a $compile minErr each a template fails to download for ngView, directives and ngMessage template requests. This changes the former behavior of silently ignoring failed HTTP requests–or when the template itself is empty. Please ensure that all directive, ngView and ngMessage code now properly addresses this scenario. NgInclude is unaffected from this change.

If any stagger code consisted of having BOTH transition staggers and delay staggers together then that will not work the same way. Angular will now instead choose the highest stagger delay value and set the timeout to wait for that before applying the active CSS class.

Both the API for the cancelation method and the done callback for $animate animations is different. Instead of using a callback function for each of the $animate animation methods, a promise is used instead.

//before
$animate.enter(element, container, null, callbackFn);

//after
$animate.enter(element, container).then(callbackFn);

The animation can now be cancelled via $animate.cancel(promise).

//before
var cancelFn = $animate.enter(element, container);
cancelFn(); //cancels the animation

//after
var promise = $animate.enter(element, container);
$animate.cancel(promise); //cancels the animation

keep in mind that you will still need to run scope.apply inside of the then callback to trigger a digest.

$animate.addClass, $animate.removeClass and $animate.setClass will no longer start the animation right after being called in the directive code. The animation will only commence once a digest has passed. This means that all animation-related testing code requires an extra digest to kick off the animation.

//before this fix
$animate.addClass(element, 'super');
expect(element).toHaveClass('super');

//now
$animate.addClass(element, 'super');
$rootScope.$digest();
expect(element).toHaveClass('super');

$animate will also tally the amount of times classes are added and removed and only animate the left over classes once the digest kicks in. This means that for any directive code that adds and removes the same CSS class on the same element then this may result in no animation being triggered at all.

$animate.addClass(element, 'klass');
$animate.removeClass(element, 'klass');

$rootScope.$digest();

//nothing happens...

The value of $binding data property on an element is always an array now and the expressions do not include the curly braces {{ ... }}.

Only cases when the currency filter is chained with another filter that doesn’t expect null/undefined will be affected. This should be very rare.

This change will not change the visual output of the filter because the interpolation will convert the null/undefined to an empty string.

Closes #8605

Only cases when the number filter is chained with another filter that doesn’t expect null/undefined will be affected. This should be very rare.

This change will not change the visual output of the filter because the interpolation will convert the null/undefined to an empty string.

Closes #8605 Closes #8842

NgModel.viewValue will always be used when rendering validations for minlength and maxlength.

Closes #7967 Closes #8811

According to the HTML5 spec input[time] should create dates based on the year 1970 (used to be based on the year 1900).

Related to #8447.

Any parser code from before that returned an undefined value (or nothing at all) will now cause a parser failure. When this occurs none of the validators present in $validators will run until the parser error is gone. The error will be stored on ngModel.$error.

The blur and focus event fire synchronously, also during DOM operations that remove elements. This lead to errors as the Angular model was not in a consistent state. See this fiddle for a demo.

This change executes the expression of those events using scope.$evalAsync if an $apply is in progress, otherwise keeps the old behavior.

Fixes #4979 Fixes #5945 Closes #8803 Closes #6910 Closes #5402

The returned value from directive controller constructors are now ignored, and only the constructed instance itself will be attached to the node’s expando. This change is necessary in order to ensure that it’s possible to bind properties to the controller’s instance before the actual constructor is invoked, as a convenience to developers.

In the past, the following would have worked:

angular.module("myApp", []).
    directive("myDirective", function() {
        return {
            controller: function($scope) {
                return {
                    doAThing: function() { $scope.thingDone = true; },
                    undoAThing: function() { $scope.thingDone = false; }
                };
            },
            link: function(scope, element, attrs, ctrl) {
                ctrl.doAThing();
            }
        };
    });

However now, the reference to doAThing() will be undefined, because the return value of the controller’s constructor is ignored. In order to work around this, one can opt for several strategies, including the use of _.extend() or merge() like routines, like so:

angular.module("myApp", []).
    directive("myDirective", function() {
        return {
            controller: function($scope) {
                _.extend(this, {
                    doAThing: function() { $scope.thingDone = true; },
                    undoAThing: function() { $scope.thingDone = false; }
                });
            },
            link: function(scope, element, attrs, ctrl) {
                ctrl.doAThing();
            }
        };
    });

# 1.2.23 superficial-malady (2014-08-22)

Bug Fixes

Breaking Changes

Previously, input[type=password] would trim values by default, and would require an explicit ng-trim=“false” to disable the trimming behavior. After this CL, ng-trim no longer affects input[type=password], and will never trim the password value.

Closes #8250 Closes #8230

# 1.3.0-beta.19 rafter-ascension (2014-08-22)

Bug Fixes

Features

Performance Improvements

Breaking Changes

Now, ng-attr-* will never add the attribute to the DOM if any of the interpolated expressions evaluate to undefined.

To work around this, initialize values which are intended to be the empty string with the empty string:

For example, given the following markup:

<div ng-attr-style="border-radius: {{value}}{{units}}"></div>

If $scope.value is 4, and $scope.units is undefined, the resulting markup is unchanged:

<div ng-attr-style="border-radius: {{value}}{{units}}"></div>

However, if $scope.units is "", then the resulting markup is updated:

<div ng-attr-style="border-radius: {{value}}{{units}}" style="border-radius: 4"></div>

Closes #8376 Closes #8399

This comment is usually needed to keep track the end boundary in the event child directives modify the root node(s). If not used for this purpose it can be safely ignored.

This change is breaking only within 1.3.0-beta releases: directive.type was renamed to directive.templateNamespace

The property name type was too general.

It’s a bad practice for filters to have hidden dependencies, so pulling stuff from scope directly is not a good idea. Scope being the filter context was never documented as public API, so we don’t expect that any significant code depends on this behavior.

If an existing filter has a dependency on the scope instance, the scope reference can be passed into the filter as a filter argument (this is highly discouraged for new code):

Before: {{ user.name | customFilter }} After: {{ user.name | customFilter:this }}

This API was available only in the last few 1.3 beta versions and is not very useful for applications, so we don’t expect that anyone will be affected by this change.

Previously, input[type=password] would trim values by default, and would require an explicit ng-trim="false" to disable the trimming behavior. After this change, ng-trim no longer affects input[type=password], and will never trim the password value.

Closes #8250 Closes #8230

# 1.3.0-beta.18 spontaneous-combustion (2014-08-12)

Bug Fixes

Features

Performance Improvements

Breaking Changes

# 1.2.22 finicky-pleasure (2014-08-12)

Bug Fixes

Features

# 1.3.0-beta.17 turing-autocompletion (2014-07-25)

Bug Fixes

Features

Performance Improvements

Breaking Changes

This means that if a directive ‘myFoo’ previously didn’t specify matching restriction, it will now match both the attribute and element form.

Before:

<div my-foo></div> <—- my-foo attribute matched the directive

<my-foo></my-foo> <—- no match

After:

<div my-foo></div> <—- my-foo attribute matched the directive

<my-foo></my-foo> <—- my-foo element matched the directive

It is not expected that this will be a problem in practice because of widespread use of prefixes that make <my-foo> like elements unlikely.

Closes #8321

# 1.2.21 wizard-props (2014-07-25)

Bug Fixes

Performance Improvements

# 1.3.0-beta.16 pizza-transubstantiation (2014-07-18)

Bug Fixes

Features

Performance Improvements

Breaking Changes

Before:

<div data-fancy-directive-start>{{start}}</div>
  <p>Grouped content</p>
<div data-fancy-directive-end>{{end}}</div>
.directive('fancyDirective', function() {
  return {
    link: angular.noop
  };
})

After:

<div data-fancy-directive-start>{{start}}</div>
  <p>Grouped content</p>
<div data-fancy-directive-end>{{end}}</div>
.directive('fancyDirective', function() {
  return {
    multiElement: true, // Explicitly mark as a multi-element directive.
    link: angular.noop
  };
})

Closes #5372 Closes #6574 Closes #5370 Closes #8044 Closes #7336

Previously, it was possible for an action passed to $watch to be a string, interpreted as an angular expression. This is no longer supported. The action now has to be a function. Passing an action to $watch is still optional.

Before:

$scope.$watch('state', ' name="" ');

After:

$scope.$watch('state', function () {
  $scope.name = "";
});

Closes #8190

If using any of the mechanisms specified above, then migrate by specifying the attribute ng-app to the root element. E.g.

<div ng-app="module">...</div>

Closes #8147

The ngList directive no longer supports splitting the view value via a regular expression. We need to be able to re-join list items back together and doing this when you can split with regular expressions can lead to inconsistent behavior and would be much more complex to support.

If your application relies upon ngList splitting with a regular expression then you should either try to convert the separator to a simple string or you can implement your own version of this directive for you application.

Closes #4008 Closes #2561 Closes #4344

** Directive Priority Changed ** - this commit changes the priority of ngSwitchWhen and ngSwitchDefault from 800 to 1200. This makes their priority higher than ngRepeat, which allows items to be repeated on the switch case element reliably.

In general your directives should have a lower priority than these directives if you want them to exist inside the case elements. If you relied on the priority of these directives then you should check that your code still operates correctly.

Closes #8235

# 1.3.0-beta.15 unbelievable-advancement (2014-07-11)

Bug Fixes

Features

Performance Improvements

Breaking Changes

$controller will no longer look for controllers on window. The old behavior of looking on window for controllers was originally intended for use in examples, demos, and toy apps. We found that allowing global controller functions encouraged poor practices, so we resolved to disable this behavior by default.

To migrate, register your controllers with modules rather than exposing them as globals:

Before:

function MyController() {
  // ...
}

After:

angular.module('myApp', []).controller('MyController', [function() {
  // ...
}]);

Although it’s not recommended, you can re-enable the old behavior like this:

angular.module('myModule').config(['$controllerProvider', function($controllerProvider) {
  // this option might be handy for migrating old apps, but please don't use it
  // in new ones!
  $controllerProvider.allowGlobals();
}]);

Previously, these attributes would always be treated as strings. However, they are now parsed as expressions, and will throw if an expression is non-constant.

To convert non-constant strings into constant expressions, simply wrap them in an extra pair of quotes, like so:

<input type="checkbox" ng-model="..." ng-true-value="'truthyValue'">

Closes #8041 Closes #5346 Closes #1199

# 1.2.20 accidental-beautification (2014-07-11)

Bug Fixes

Features

# 1.3.0-beta.14 harmonious-cacophonies (2014-06-30)

This release contains security fixes for $parse that prevent arbitrary code execution via Angular expressions under some very specific conditions. The only applications affected by these vulnerabilities are those that match all of the following conditions:

Applications not meeting all of the conditions are not vulnerable.

This fix is in both 1.3.0-beta.14 and 1.2.19 release.

The Angular team would like to thank Jann Horn for reporting these vulnerabilities via [security@angularjs.org].

Bug Fixes

Features

Performance Improvements

Breaking Changes

You can no longer invoke .bind, .call or .apply on a function in angular expressions. This is to disallow changing the behavior of existing functions in an unforeseen fashion. - due to 6081f207,

The (deprecated) proto property does not work inside angular expressions anymore. - due to 48fa3aad,

This prevents the use of {define,lookup}{Getter,Setter} inside angular expressions. If you really need them for some reason, please wrap/bind them to make them less dangerous, then make them available through the scope object. - due to 528be29d,

This prevents the use of Object inside angular expressions. If you need Object.keys, make it accessible in the scope. - Angular.copy: due to b59b04f9,

This changes angular.copy so that it applies the prototype of the original object to the copied object. Previously, angular.copy would copy properties of the original object’s prototype chain directly onto the copied object.

This means that if you iterate over only the copied object’s hasOwnProperty properties, it will no longer contain the properties from the prototype. This is actually much more reasonable behavior and it is unlikely that applications are actually relying on this.

If this behavior is relied upon, in an app, then one should simply iterate over all the properties on the object (and its inherited properties) and not filter them with hasOwnProperty.

Be aware that this change also uses a feature that is not compatible with IE8. If you need this to work on IE8 then you would need to provide a polyfill for Object.create and Object.getPrototypeOf. - core: due to bdfc9c02, values ‘f’, ‘0’, ‘false’, ‘no’, ‘n’, ‘[]’ are no longer treated as falsy. Only JavaScript falsy values are now treated as falsy by the expression parser; there are six of them: false, null, undefined, NaN, 0 and "".

Closes #3969 Closes #4277 Closes #7960

Previously, even if invokeApply was set to false, a $rootScope digest would occur during promise resolution. This is no longer the case, as promises returned from $timeout and $interval will no longer trigger $evalAsync (which in turn causes a $digest) if invokeApply is false.

Workarounds include manually triggering scope.apply(), or returning $q.defer().promise from a promise callback, and resolving or rejecting it when appropriate.

var interval = $interval(function() {
  if (someRequirementFulfilled) {
    $interval.cancel(interval);
    $scope.$apply();
  }
}, 100, 0, false);

or:

var interval = $interval(function (idx) {
  // make the magic happen
}, 1000, 10, false);
interval.then(function(idx) {
  var deferred = $q.defer();
  // do the asynchronous magic --- $evalAsync will cause a digest and cause
  // bindings to update.
  return deferred.promise;
});

# 1.2.19 precognitive-flashbacks (2014-06-30)

Bug Fixes

Performance Improvements

Breaking Changes

You can no longer invoke .bind, .call or .apply on a function in angular expressions. This is to disallow changing the behavior of existing functions in an unforeseen fashion. - due to cb713e60,

The (deprecated) proto property does not work inside angular expressions anymore. - due to 89ca8597,

This prevents the use of {define,lookup}{Getter,Setter} inside angular expressions. If you really need them for some reason, please wrap/bind them to make them less dangerous, then make them available through the scope object. - due to bc6fb7cc,

This prevents the use of Object inside angular expressions. If you need Object.keys, make it accessible in the scope.

# 1.3.0-beta.13 idiosyncratic-numerification (2014-06-16)

Bug Fixes

# 1.3.0-beta.12 ephemeral-acceleration (2014-06-13)

Bug Fixes

Features

Performance Improvements

Breaking Changes

Requesting isolate scope and any other scope on a single element is an error. Before this change, the compiler let two directives request a child scope and an isolate scope if the compiler applied them in the order of non-isolate scope directive followed by isolate scope directive.

Now the compiler will error regardless of the order.

If you find that your code is now throwing a $compile:multidir error, check that you do not have directives on the same element that are trying to request both an isolate and a non-isolate scope and fix your code.

Closes #4402 Closes #4421 - NgModel: due to 1be9bb9d,

If an expression is used on ng-pattern (such as ng-pattern="exp") or on the pattern attribute (something like on pattern="{{ exp }}") and the expression itself evaluates to a string then the validator will not parse the string as a literal regular expression object (a value like /abc/i). Instead, the entire string will be created as the regular expression to test against. This means that any expression flags will not be placed on the RegExp object. To get around this limitation, use a regular expression object as the value for the expression.

//before
$scope.exp = '/abc/i';

//after
$scope.exp = /abc/i;

This change also makes our forEach behave more like Array#forEach. - jqLite: due to a196c8bc, previously it was possible to set jqLite data on Text/Comment nodes, but now that is allowed only on Element and Document nodes just like in jQuery. We don’t expect that app code actually depends on this accidental feature.

# 1.2.18 ear-extendability (2014-06-13)

Bug Fixes

Performance Improvements

# 1.3.0-beta.11 transclusion-deforestation (2014-06-06)

Bug Fixes

Features

Breaking Changes

The isolated scope of a component directive no longer leaks into the template that contains the instance of the directive. This means that you can no longer access the isolated scope from attributes on the element where the isolated directive is defined.

See https://github.com/angular/angular.js/issues/10236 for an example.

# 1.2.17 - quantum disentanglement (2014-06-06)

Bug Fixes

Features

Performance Improvements

# 1.3.0-beta.10 excessive-clarification (2014-05-23)

Bug Fixes

Features

Performance Improvements

Breaking Changes

# 1.3.0-beta.9 release-naming (2014-05-16)

Bug Fixes

Features

Breaking Changes

# 1.3.0-beta.8 accidental-haiku (2014-05-09)

Bug Fixes

Features

Breaking Changes

Previously, it was possible to register a response interceptor like so:

// register the interceptor as a service
$provide.factory('myHttpInterceptor', function($q, dependency1, dependency2) {
  return function(promise) {
    return promise.then(function(response) {
      // do something on success
      return response;
    }, function(response) {
      // do something on error
      if (canRecover(response)) {
        return responseOrNewPromise
      }
      return $q.reject(response);
    });
  }
});

$httpProvider.responseInterceptors.push('myHttpInterceptor');

Now, one must use the newer API introduced in v1.1.4 (4ae46814), like so:

$provide.factory('myHttpInterceptor', function($q) {
  return {
    response: function(response) {
      // do something on success
      return response;
    },
    responseError: function(response) {
      // do something on error
      if (canRecover(response)) {
        return responseOrNewPromise
      }
      return $q.reject(response);
    }
  };
});

$httpProvider.interceptors.push('myHttpInterceptor');

More details on the new interceptors API (which has been around as of v1.1.4) can be found at https://docs.angularjs.org/api/ng/service/$http#interceptors

Previously, config blocks would be able to control behavior of provider registration, due to being invoked prior to provider registration. Now, provider registration always occurs prior to configuration for a given module, and therefore config blocks are not able to have any control over a providers registration.

Example:

Previously, the following:

angular.module('foo', [])
  .provider('$rootProvider', function() {
    this.$get = function() { ... }
  })
  .config(function($rootProvider) {
    $rootProvider.dependentMode = "B";
  })
  .provider('$dependentProvider', function($rootProvider) {
     if ($rootProvider.dependentMode === "A") {
       this.$get = function() {
        // Special mode!
       }
     } else {
       this.$get = function() {
         // something else
       }
    }
  });

would have “worked”, meaning behavior of the config block between the registration of “$rootProvider" and "$dependentProvider” would have actually accomplished something and changed the behavior of the app. This is no longer possible within a single module.

This commit changes the API on NgModelController, both semantically and in terms of adding and renaming methods.

To migrate code that used $cancelUpdate() follow the example below:

Before:

$scope.resetWithCancel = function (e) {
  if (e.keyCode == 27) {
    $scope.myForm.myInput1.$cancelUpdate();
    $scope.myValue = '';
  }
};

After:

$scope.resetWithCancel = function (e) {
  if (e.keyCode == 27) {
    $scope.myForm.myInput1.$rollbackViewValue();
    $scope.myValue = '';
  }
}

# v1.3.0-beta.7 proper-attribution (2014-04-25)

Bug Fixes

Performance Improvements

# v1.3.0-beta.6 expedient-caffeination (2014-04-21)

Bug Fixes

Features

Performance Improvements

Breaking Changes

# 1.3.0-beta.5 chimeric-glitterfication (2014-04-03)

Bug Fixes

Breaking Changes

To update existing code, change all instances of $animate.enter() or $animate.move() from:

$animate.enter(element, parent);

to:

$animate.enter(element, parent, angular.element(parent[0].lastChild));

# 1.2.16 badger-enumeration (2014-04-03)

Bug Fixes

Features

# 1.3.0-beta.4 inconspicuous-deception (2014-03-28)

Bug Fixes

Features

Breaking Changes

Before:

.animated.my-class-add {
  opacity:0;
  transition:0.5s linear all;
}
.animated.my-class-add.my-class-add-active {
  opacity:1;
}

After:

.animated.my-class-add {
  transition:0s linear all;
  opacity:0;
}
.animated.my-class-add.my-class-add-active {
  transition:0.5s linear all;
  opacity:1;
}

Please view the documentation for ngAnimate for more info.

# 1.3.0-beta.3 emotional-waffles (2014-03-21)

Bug Fixes

Features

Breaking Changes

Before:

directive('directiveName', function() {
  return {
    link: function(scope, elm, attr) {
      var observer = attr.$observe('someAttr', function(value) {
        console.log(value);
      });
    }
  };
});

After:

directive('directiveName', function() {
  return {
    link: function(scope, elm, attr) {
      var observer = function(value) {
        console.log(value);
      };

      attr.$observe('someAttr', observer);
    }
  };
});

# v1.2.15 beer-underestimating (2014-03-21)

Bug Fixes

# 1.3.0-beta.2 silent-ventriloquism (2014-03-14)

Bug Fixes

Features

# 1.3.0-beta.1 retractable-eyebrow (2014-03-07)

Bug Fixes

Features

Breaking Changes

For more info: http://blog.angularjs.org/2013/12/angularjs-13-new-release-approaches.html

# 1.2.14 feisty-cryokinesis (2014-03-01)

Bug Fixes

Features

Performance Improvements

# 1.2.13 romantic-transclusion (2014-02-14)

Bug Fixes

Features

Breaking Changes

# 1.2.12 cauliflower-eradication (2014-02-07)

Bug Fixes