This fixes an inconsistency where you can't call the setter function
when the expression resolves to a top level field name on a promise.
Setting a field on an unresolved promise will throw an exception. (This
shouldn't really happen in your template/js code and points to a
programming error.)
Closes#1827
Ghost clicks are busted but the corresponding form elements are still focused. This means that for example on smartphones the soft keyboard will be opened. This pull request prevents the unwanted opening of the soft keyboard.
The global jQuery reference is removed by angular scenario and only a local scoped reference is kept. To make jQuery available for other code, a new reference angular.scenario.jQuery is added.
Normally $exceptionHandler doesn't throw an exception. It is normally
used just for logging and so on. But if an application developer
implemented a version that did throw an exception then $q would never
have called reject() when converting an exception thrown inside a `then`
handler into a rejected promise.
When using $resource you must setup your actions carefully based on what the server returns.
If the server responds to a request with an array then you must configure the action with
`isArray:true` and vice versa. The built-in `get` action defaults to `isArray:false` and the
`query` action defaults to `isArray:true`, which is must be changed if the server does not do this.
Before the error message was an exception inside angular.copy, which didn't explain what the
real problem was. Rather than changing the way that angular.copy works, this change ensures that
a better error message is provided to the programmer if they do not set up their resource actions
correctly.
Closes#2255, #1044
Change the implementation of isArrayLike to use one heavily based on the
implementation in jQuery in order to correctly detect array-like
objects, that way functionality like ngRepeat works as expected.
Support controller: 'MyController as my' syntax for directives which publishes
the controller instance to the directive scope.
Support controllerAs syntax to define an alias to the controller within the
directive scope.
If ngClass fires off an add- or removeClass whilst the opposite animation is going on then
the animation will be skipped. The default behavior of ngClass was executing remoteClass
with an empty string while addClass had just fired. This commit fixes that bug.
BREAKING CHANGE: previously ngView only updated its content, after this change
ngView will recreate itself every time a new content is included. This ensures
that a single rootElement for all the included contents always exists, which makes
definition of css styles for animations much easier.
BREAKING CHANGE: previously ngInclude only updated its content, after this change
ngInclude will recreate itself every time a new content is included. This ensures
that a single rootElement for all the included contents always exists, which makes
definition of css styles for animations much easier.
- ngAnimate directive is gone and was replaced with class based animations/transitions
- support for triggering animations on css class additions and removals
- done callback was added to all animation apis
- $animation and $animator where merged into a single $animate service with api:
- $animate.enter(element, parent, after, done);
- $animate.leave(element, done);
- $animate.move(element, parent, after, done);
- $animate.addClass(element, className, done);
- $animate.removeClass(element, className, done);
BREAKING CHANGE: too many things changed, we'll write up a separate doc with migration instructions
the $timeout mock's flush method allows flushing queued up requests
but doesn't allow to for checking with what delay a task was queued
up. flushNext flushes the next queued up task and can asserts the
scheduled delay.
Similar to ngMobile clicks, these events were not capturable by other
directives. Now they emit 'swipeleft' and 'swiperight' events that can
be follow with element.on('swipeleft', ...).
Changes:
- remove ng-bind-html-unsafe
- ng-bind-html is now in core
- ng-bind-html is secure
- supports SCE - so you can bind to an arbitrary trusted string
- automatic sanitization if $sanitize is available
BREAKING CHANGE:
ng-html-bind-unsafe has been removed and replaced by ng-html-bind
(which has been removed from ngSanitize.) ng-bind-html provides
ng-html-bind-unsafe like behavior (innerHTML's the result without
sanitization) when bound to the result of $sce.trustAsHtml(string).
When bound to a plain string, the string is sanitized via $sanitize
before being innerHTML'd. If $sanitize isn't available, it's logs an
exception.
$sce is a service that provides Strict Contextual Escaping services to AngularJS.
Strict Contextual Escaping
--------------------------
Strict Contextual Escaping (SCE) is a mode in which AngularJS requires
bindings in certain contexts to result in a value that is marked as safe
to use for that context One example of such a context is binding
arbitrary html controlled by the user via ng-bind-html-unsafe. We
refer to these contexts as privileged or SCE contexts.
As of version 1.2, Angular ships with SCE enabled by default.
Note: When enabled (the default), IE8 in quirks mode is not supported.
In this mode, IE8 allows one to execute arbitrary javascript by the use
of the expression() syntax. Refer
http://blogs.msdn.com/b/ie/archive/2008/10/16/ending-expressions.aspx
to learn more about them. You can ensure your document is in standards
mode and not quirks mode by adding <!doctype html> to the top of your
HTML document.
SCE assists in writing code in way that (a) is secure by default and (b)
makes auditing for security vulnerabilities such as XSS, clickjacking,
etc. a lot easier.
Here's an example of a binding in a privileged context:
<input ng-model="userHtml">
<div ng-bind-html-unsafe="{{userHtml}}">
Notice that ng-bind-html-unsafe is bound to {{userHtml}} controlled by
the user. With SCE disabled, this application allows the user to render
arbitrary HTML into the DIV. In a more realistic example, one may be
rendering user comments, blog articles, etc. via bindings. (HTML is
just one example of a context where rendering user controlled input
creates security vulnerabilities.)
For the case of HTML, you might use a library, either on the client side, or on the server side,
to sanitize unsafe HTML before binding to the value and rendering it in the document.
How would you ensure that every place that used these types of bindings was bound to a value that
was sanitized by your library (or returned as safe for rendering by your server?) How can you
ensure that you didn't accidentally delete the line that sanitized the value, or renamed some
properties/fields and forgot to update the binding to the sanitized value?
To be secure by default, you want to ensure that any such bindings are disallowed unless you can
determine that something explicitly says it's safe to use a value for binding in that
context. You can then audit your code (a simple grep would do) to ensure that this is only done
for those values that you can easily tell are safe - because they were received from your server,
sanitized by your library, etc. You can organize your codebase to help with this - perhaps
allowing only the files in a specific directory to do this. Ensuring that the internal API
exposed by that code doesn't markup arbitrary values as safe then becomes a more manageable task.
In the case of AngularJS' SCE service, one uses $sce.trustAs (and
shorthand methods such as $sce.trustAsHtml, etc.) to obtain values that
will be accepted by SCE / privileged contexts.
In privileged contexts, directives and code will bind to the result of
$sce.getTrusted(context, value) rather than to the value directly.
Directives use $sce.parseAs rather than $parse to watch attribute
bindings, which performs the $sce.getTrusted behind the scenes on
non-constant literals.
As an example, ngBindHtmlUnsafe uses $sce.parseAsHtml(binding
expression). Here's the actual code (slightly simplified):
var ngBindHtmlUnsafeDirective = ['$sce', function($sce) {
return function(scope, element, attr) {
scope.$watch($sce.parseAsHtml(attr.ngBindHtmlUnsafe), function(value) {
element.html(value || '');
});
};
}];
Impact on loading templates
---------------------------
This applies both to the ng-include directive as well as templateUrl's
specified by directives.
By default, Angular only loads templates from the same domain and
protocol as the application document. This is done by calling
$sce.getTrustedResourceUrl on the template URL. To load templates from
other domains and/or protocols, you may either either whitelist them or
wrap it into a trusted value.
*Please note*:
The browser's Same Origin Policy and Cross-Origin Resource Sharing
(CORS) policy apply in addition to this and may further restrict whether
the template is successfully loaded. This means that without the right
CORS policy, loading templates from a different domain won't work on all
browsers. Also, loading templates from file:// URL does not work on
some browsers.
This feels like too much overhead for the developer?
----------------------------------------------------
It's important to remember that SCE only applies to interpolation expressions.
If your expressions are constant literals, they're automatically trusted
and you don't need to call $sce.trustAs on them.
e.g. <div ng-html-bind-unsafe="'<b>implicitly trusted</b>'"></div> just works.
Additionally, a[href] and img[src] automatically sanitize their URLs and
do not pass them through $sce.getTrusted. SCE doesn't play a role here.
The included $sceDelegate comes with sane defaults to allow you to load
templates in ng-include from your application's domain without having to
even know about SCE. It blocks loading templates from other domains or
loading templates over http from an https served document. You can
change these by setting your own custom whitelists and blacklists for
matching such URLs.
This significantly reduces the overhead. It is far easier to pay the
small overhead and have an application that's secure and can be audited
to verify that with much more ease than bolting security onto an
application later.
Previously, no handlers for the click event would be called for the
fast, touch-based ngMobile clicks, only for desktop browser clicks. Now
the event will fire properly for all clicks.
Closes#3219Closes#3218Closes#3137
changing the type of select box from single to multiple or the other way around
at runtime is currently not supported and the two-way binding does odd stuff
when such situation happens.
we might eventually support this, but for now we are just going to not allow
binding to select[multiple] to prevent people from relying on something that
doesn't work.
BREAKING CHANGE: binding to select[multiple] directly or via ngMultiple (ng-multiple)
directive is not supported. This feature never worked with two-way data-binding,
so it's not expected that anybody actually depends on it.
Closes#3230
- the ngClick attribute was always triggered, regardless the ngDisabled/disabled attributes
- we now check the DOM disabled status before triggering the original click event
Closes#3124Closes#3132
Previously, the number filter would format small and large numbers
as scientific notation. It now uses toFixed() to ensure that all
requested digits are shown.
angular.equals was returning inconsistent values for the comparison between
{} and []:
angular.equals({}, []) // true
angular.equals([], {}]) // false
Since these object are not of the same type, they should not be considered
equivalent.
If an app uses HTML5 mode and we open an html5 url on IE8 or 9 which
don't support location href, we use location.replace to reload the page
with the hashbang equivalent of the url but this fails with infinite
digest. This is because location.replace doesn't update location.href
synchronously on IE8 and 9.
Closes#2802, #3305, #1417
ngScenario expects an ngApp directive to be used, and doesn't work for
manually bootstrapped apps. The failure mode is to hang on navigation.
Trying to make this wont-fix bug less obscure by documenting it.
Eventually Protractor will replace ngScenario and fix this.
