A common mistake for beginners is to attach a controller in both the
$routeProvider and also in the html document using the ng-controller
directive. This change highlights this, to help prevent developers from
doing so in the future.
Closes#4409
When we refactored , we broke the csp mode because the previous implementation
relied on the fact that it was ok to lazy initialize the .csp property, this
is not the case any more.
Besides, we need to know about csp mode during bootstrap and avoid injecting the
stylesheet when csp is active, so I refactored the code to fix both issues.
PR #4411 will follow up on this commit and add more improvements.
Closes#917Closes#2963Closes#4394Closes#4444
BREAKING CHANGE: triggering ngCsp directive via `ng:csp` attribute is not
supported any more. Please use data-ng-csp instead.
Issue an error and abort compilation when two directives that ask for transclusion are found
on a single element. This configuration is not supported and we previously failed to issue
the error because in the case of element transclusion the compilation is re-started and this
caused the compilation context to be lost.
The ngRepeat directive has been special-cased to bypass this warning because it knows how to
handle this scenario internally.
This is not an ideal solution to the problem of multiple transclusions per element, we are
hoping to have this configuration supported by the compiler in the future. See #4357.
Closes#3893Closes#4217Closes#3307
BREAKING CHANGE: the priority of ngRepeat, ngSwitchWhen, ngIf,
ngInclude and ngView has changed. This could affect directives that
explicitly specify their priority.
In order to make ngRepeat, ngSwitchWhen, ngIf, ngInclude and ngView
work together in all common scenarios their directives are being
adjusted to achieve the following precendence:
Directive | Old Priority | New Priority
=============================================
ngRepeat | 1000 | 1000
---------------------------------------------
ngSwitchWhen | 500 | 800
---------------------------------------------
ngIf | 1000 | 600
---------------------------------------------
ngInclude/ngView | 1000 | 400
Array.prototype.sort is speced out to be as potentionally unstable sort,
which is how it's implemented in FF and IE. This has caused the order
of directives with the same priority to vary between browsers.
For consistency sake, we now consider directive name and registration,
order when determining the order of directives with the same priority.
Note: it is still possible to get into a situation when the directive
order is underministic - when source files are loaded asynchronously
in non-deterministic order and there are are directives registered
with the same name and priority, the order in which they will be applied
will depend on the file load order.
The location service, and other portions of the application,
were relying on a complicated regular expression to get parts of a URL.
But there is already a private urlUtils provider,
which relies on HTMLAnchorElement to provide this information,
and is suitable for most cases.
In order to make urlUtils more accessible in the absence of DI,
its methods were converted to standalone functions available globally.
The urlUtils.resolve method was renamed urlResolve,
and was refactored to only take 1 argument, url,
and not the 2nd "parse" boolean.
The method now always returns a parsed url.
All places in code which previously wanted a string instead of a parsed
url can now get the value from the href property of the returned object.
Tests were also added to ensure IPv6 addresses were handled correctly.
Closes#3533Closes#2950Closes#3249
Issue: multi-elements ng-repeat (ng-repeat-start, ng-repeat-end) can contain elements with a trancluding directive. This directive changes content of the row (template) and ng-repeat does not work correctly (when removing/moving rows), because ng-repeat works with the original template (elements).
This changes ng-repeat behavior to traverse the DOM to find current elements everytime we are moving/removing rows (if the template has multiple elements).
Closes#3104
This reverts commit 3a65822023.
The change cased regressions in third party components that require
promises from getter functions not to be unwrapped.
Since we have deprecated the promise unwrapping support in $parse it
doesn't make much sense to fix this issue and deal with regressions in
third party code.
Closes#4158
This commit disables promise unwrapping and adds
$parseProvider.unwrapPromises() getter/setter api that allows developers
to turn the feature back on if needed. Promise unwrapping support will
be removed from Angular in the future and this setting only allows for
enabling it during transitional period.
If the unwrapping is enabled, Angular will log a warning about each
expression that unwraps a promise (to reduce the noise, each expression
is logged only onces). To disable this logging use
`$parseProvider.logPromiseWarnings(false)`.
Previously promises found anywhere in the expression during expression
evaluation would evaluate to undefined while unresolved and to the
fulfillment value if fulfilled.
This is a feature that didn't prove to be wildly useful or popular,
primarily because of the dichotomy between data access in templates
(accessed as raw values) and controller code (accessed as promises).
In most code we ended up resolving promises manually in controllers
or automatically via routing and unifying the model access in this way.
Other downsides of automatic promise unwrapping:
- when building components it's often desirable to receive the
raw promises
- adds complexity and slows down expression evaluation
- makes expression code pre-generation unattractive due to the
amount of code that needs to be generated
- makes IDE auto-completion and tool support hard
- adds too much magic
BREAKING CHANGE: $parse and templates in general will no longer
automatically unwrap promises. This feature has been deprecated and
if absolutely needed, it can be reenabled during transitional period
via `$parseProvider.unwrapPromises(true)` api.
Closes#4158Closes#4270
Changed controller name in example html to ScrollCtrl to match name in example js.
Add styling to example html so scrollable area is not obtrusive to documentation page design.
Closes#3898
`checkboxInputType` and `ngList` directives need to have special logic for whether
they are empty or not. Previously this had been hard coded into their
own directives or the `ngRequired` directive. This made it difficult to handle
these special cases.
This change factors out the question of whether an input is empty into a method
`$isEmpty` on the `ngModelController`. The `ngRequired` directive now uses this
method when testing for validity and directives, such as `checkbox` or `ngList`
can override it to apply logic specific to their needs.
Closes#3490, #3658, #2594
The $interval service simplifies creating and testing recurring tasks.
This service does not increment $browser's outstanding request count,
which means that scenario tests and Protractor tests will not timeout
when a site uses a polling function registered by $interval. Provides
a workaround for #2402.
For unit tests, repeated tasks can be controlled using ngMock$interval's
tick(), tickNext(), and tickAll() functions.
This reverts commit 281feba4ca.
Since Lexer and Parser objects are stateful it is not safe
to reuse them for parsing of multiple expressions.
After recent refactoring into prototypical style, the instantiation
of these objects is so cheap that it's not a huge win to use
singletons here.
Objects received from outside AngularJS may have had their `hasOwnProperty`
method overridden with something else. In cases where we can do this without
incurring a performance penalty we call directly on Object.prototype.hasOwnProperty
to ensure that we use the correct method.
Also, we have some internal hash objects, where the keys for the map are provided
from outside AngularJS. In such cases we either prevent `hasOwnProperty` from
being used as a key or provide some other way of preventing our objects from
having their `hasOwnProperty` overridden.
BREAKING CHANGE: Inputs with name equal to "hasOwnProperty" are not allowed inside
form or ngForm directives.
Before, inputs whose name was "hasOwnProperty" were quietly ignored and not added
to the scope. Now a badname exception is thrown.
Using "hasOwnProperty" for an input name would be very unusual and bad practice.
Either do not include such an input in a `form` or `ngForm` directive or change
the name of the input.
Closes#3331
This reduces memory consumption of parsed angular expressions and
speeds up parsing.
This JSPerf case demonstrates the performance boost:
http://jsperf.com/closure-vs-prototype-ngparser
Chrome: 1.5–2x boost
FF: slightly slower (I would love to know why)
IE: 4x boost
To be clear, this doesn't have any impact on runtime performance
of expressions as demostrated in this JSPerf:
http://jsperf.com/angular-parser-changesCloses#3681
previously the compile/link fns executed in this order controlled via priority:
- CompilePriorityHigh, CompilePriorityMedium, CompilePriorityLow
- PreLinkPriorityHigh, PreLinkPriorityMedium, PreLinkPriorityLow
- link children
- PostLinkPriorityHigh, PostLinkPriorityMedium, PostLinkPriorityLow
This was changed to:
- CompilePriorityHigh, CompilePriorityMedium, CompilePriorityLow
- PreLinkPriorityHigh, PreLinkPriorityMedium, PreLinkPriorityLow
- link children
- PostLinkPriorityLow, PostLinkPriorityMedium , PostLinkPriorityHigh
Using this order the child transclusion directive that gets replaced
onto the current element get executed correctly (see issue #3558),
and more generally, the order of execution of post linking function
makes more sense. The incorrect order was an oversight that has
gone unnoticed for many suns and moons.
(FYI: postLink functions are the default linking functions)
BREAKING CHANGE: the order of postLink fn is now mirror opposite of
the order in which corresponding preLinking and compile functions
execute.
Very few directives in practice rely on order of postLinking function
(unlike on the order of compile functions), so in the rare case
of this change affecting an existing directive, it might be necessary
to convert it to a preLinking function or give it negative priority
(look at the diff of this commit to see how an internal attribute
interpolation directive was adjusted).
Closes#3558
Previously we would stop the compilation for both regular and element
transclusion directives which was wrong. Only element transclusion directives
should be terminal.
Refactored `replacedUrl` to store the new URL on both
`location.replace` and setting `location.href` directly to handle
delays in the actual location value change in IE.
Closes#2802
The current comment of Attributes.$observe doesn't state correctly the behavior when the attribute contains no interpolation. Specifically, it states that the observer function will never be invoked if the attribute contains no interpolation. However, the actual behavior in this case is that the observer will be invoked once during the next digest loop.
Fix wrong behaviour that didn't allow 'data-on' and 'on' element attributes
to be interpolated by $compile. The regex now accepts any string beginning
with 'on' and with at least one more English letter.
This is a breaking change. To migrate to the new behavior,
delete or set headers to `undefined` to avoid having them sent.
To restore the old behavior, override `$httpBackendProvider`
with the old implementation.
Closes#2984
The `XMLHttpRequest.send` spec defines different semantics for `null`
than for an empty String: an empty String should be sent with a
`Content-Type` of `text/plain`, whereas `null` should have no
`Content-Type` header set.
Closes#2149
This feature adds similar functionality to what `$ControllerProvider.register`
and `$CompileProvider.directive` currently provide by allowing a map of filter
name/factories to be passed as the sole argument to `$FilterProvider.register`
to register all of the specified filters.
Closes#4036Closes#4091
How did compiling a templateUrl (async) directive with `replace:true` work before this commit?
1/ apply all directives with higher priority than the templateUrl directive
2/ partially apply the templateUrl directive (create `beforeTemplateNodeLinkFn`)
3/ fetch the template
4/ apply second part of the templateUrl directive on the fetched template
(`afterTemplateNodeLinkFn`)
That is, the templateUrl directive is basically split into two parts (two `nodeLinkFn` functions),
which has to be both applied.
Normally we compose linking functions (`nodeLinkFn`) using continuation - calling the linking
function of a parent element, passing the linking function of the child elements as an argument. The
parent linking function then does:
1/ execute its pre-link functions
2/ call the child elements linking function (traverse)
3/ execute its post-link functions
Now, we have two linking functions for the same DOM element level (because the templateUrl directive
has been split).
There has been multiple issues because of the order of these two linking functions (creating
controller before setting up scope locals, running linking functions before instantiating
controller, etc.). It is easy to fix one use case, but it breaks some other use case. It is hard to
decide what is the "correct" order of these two linking functions as they are essentially on the
same level.
Running them side-by-side screws up pre/post linking functions for the high priority directives
(those executed before the templateUrl directive). It runs post-linking functions before traversing:
```js
beforeTemplateNodeLinkFn(null); // do not travers
afterTemplateNodeLinkFn(afterTemplateChildLinkFn);
```
Composing them (in any order) screws up the order of post-linking functions. We could fix this by
having post-linking functions to execute in reverse order (from the lowest priority to the highest)
which might actually make a sense.
**My solution is to remove this splitting.** This commit removes the `beforeTemplateNodeLinkFn`. The
first run (before we have the template) only schedules fetching the template. The rest (creating
scope locals, instantiating a controller, linking functions, etc) is done when processing the
directive again (in the context of the already fetched template; this is the cloned
`derivedSyncDirective`).
We still need to pass-through the linking functions of the higher priority directives (those
executed before the templateUrl directive), that's why I added `preLinkFns` and `postLinkFns`
arguments to `applyDirectivesToNode`.
This also changes the "$compile transclude should make the result of a transclusion available to the
parent directive in post- linking phase (templateUrl)" unit test. It was testing that a parent
directive can see the content of transclusion in its pre-link function. That is IMHO wrong (as the
`ngTransclude` directive inserts the translusion in its linking function). This test was only passing because of
c173ca4128, which changed the behavior of the compiler to traverse
before executing the parent linking function. That was wrong and also caused the #3792 issue, which
this change fixes.
Closes#3792Closes#3923Closes#3935Closes#3927
In the Android browser, the BFCache maintains
the state of JavaScript applications even when
navigating to another app, so that going
forward and back, to and from an application
is very fast.
Unfortunately, this can have undesired side
effects. In this instance, the location
variable was holding a reference to a stale
window.location, and was throwing errors
when going back to an Angular app after
browsing to another site.
This fix makes sure that location.url()
includes a check to make sure that location
is referencing the current window.location.
Closes#4044
jqLite previously used `elt.className` to add and remove classes from a DOM Node, but
because the className property is not writable on SVG elements, it doesn't work with
them. This patch replaces accesses to `className` with `get/setAttribute`.
`classList` was also considered as a solution, but because only IE10+ supports it, we
have to wait. :'(
The JqLiteAddClass/JQLiteRemoveClass methods are now also used directly by $animate
to work around the jQuery not being able to handle class modifications on SVG elements.
Closes#3858
The problem was in keeping the values of `attrNameStart` and `attrNameEnd` between directive loop iterations which lead to the compiler looking for multi-element ranges for any directives that happened to be in the directive list after one that was applied on a range. For instance, having a ng-repeat-start and ng-class on a single element with ng-repeat being resolved first made the compiler look for an ng-repeat-end for both ng-repeat and ng-class because the `attrNameEnd` was not reset to a falsy value before the second iteration. As the result, an exception saying the block end element could not be found and the second directive was not actually applied.
Closes#4002
jQuery 1.10.2 does not attach data to comment nodes, which previously broke `$compile`.
This changes how elements with "transclude element" and a controller are compiled to
avoid the issue.
Closes#3764
Initially, `$httpProvider.defaults.headers.get` is `undefined`, so
`$httpProvider.defaults.headers.get['My-Header']='value'` will throw an
error.
Closes#4101
Previously if the collection model was set to undefined on the first digest,
the repeater would get confused and not use the correct tracking function
for associating model with dom elements in the repeater.
Closes#4145Closes#3964
Ref: https://github.com/angular/angular.js/pull/4045
I have this sinking feeling that support this use case sort of
encourages binding to function that blindly trust some html. For now,
I'm fixing the issue while I think about the use cases some more.
In the case of a function that performs any non-trivial work before
wrapping the value (e.g. the showdown filter in issue #3980, or the
binding to a simply wrapper function in issue #3932 if it did anything
meaty), this fix makes it "work" - but performance is going to suck -
you should bind to some other thing on scope that watches the actual
source and adjusts itself when that changes (e.g. the showdown filter.)
For the case of the wrapper in #3932, if one isn't performing
sanitization or some such thing - then you the developer has insight
into why that value is safe in that particular context - and it should
be available simply by name and not as a result of a function taking any
arbitrary input to make auditing of security a little saner.
Closes#3932, #3980
BREAKING CHANGE: ngInclude's priority is now set to 1000
It's quite rare for anyone to depend on explicity directive priority,
but if a custom directive that needs to run before ngInclude exists,
it should have its priority checked and adjusted if needed.
Closes#3793
- Add proper ngdoc annotations to existing $observe documentation
- Add link to directive guide for usage example of $observe
- Add note about $observe function parameter signature
Closes#3957
It's great that IE11 wants to be compatible enough that it doesn't want
to be special cased and treated differently.
However, as long as one has to have a different code path for IE than
for the other supported browsers, we still need to detect and special
case it. For instance, our URL parsing code still needs the same
workaround the we used for IE10. We still see the same Access denied /
TypeError exceptions when setting certain values. FYI, Angular doesn't
generally blindly test for IE – we also check the version number.
Thanks to modern.ie for the free IE11 test VM.
Closes#3682
This change causes a new $digest to be scheduled in the next tick if
a task was was sent to the $evalAsync queue from outside of a $digest
or an $apply.
While this mode of operation is not common for most of the user code,
this change means that $q promises that utilze $evalAsync queue to
guarantee asynchronicity of promise apis will now also resolve outside
of a $digest, which turned out to be a big pain point for some developers.
The implementation ensures that we don't do more work than needed and
that we coalese as much work as possible into a single $digest.
The use of $browser instead of setTimeout ensures that we can mock out
and control the scheduling of "auto-flush", which should in theory
allow all of the existing code and tests to work without negative
side-effects.
Closes#3539Closes#2438
This reverts commit 637c9b1611.
(ref #3633 and #3646)
The minimum bar for $sce is IE8 in standards mode. IE7 standards mode
is not supported. If you must support IE7, you should disable $sce
completely.
angular.module('ie7support', []).config(function($sceProvider) {
// Completely disable SCE to support IE7.
$sceProvider.enabled(false);
});
Changes documentMode test version to 7 in order to support IE 8 in IE 7 standards
mode while still protecting against quirks mode.
documentMode returns the following values:
5 - quirks mode,
7 - IE 7 standards mode,
8 - IE 8 standards mode.
Closes#3633Closes#3646
when the transluded content is being teleported to the translusion point, we should ensure that
the translusion point is empty before appending otherwise we end up with junk before the transcluded
content
previously the translusion was appended the the ngTranslude element via
$evalAsync which makes the transluded dom unavailable to parent
post-linking functions. By appending translusion in linking phase,
post-linking functions will be able to access it.
Code was evaluating !expression[key] while attempting to
see if the key was present, but this was evaluating to true for
false values as well as missing keys.
Closes#2797.
Make sure $timeout callbacks are forgotten about immediately after
execution or cancellation.
Previously when passing invokeApply=false, the cleanup used $q and so
would be pending until the next $digest was triggered. This does not
make a large functional difference, but can be very visible when
looking at memory consumption of an app or debugging around the
$$asyncQueue - these callbacks can have a big retaining tree.
After a recent refactoring using $location in the default hashbang mode would result
in hash url being initialized unnecessarily in cases when the base url didn't end
with a slash.
for example http://localhost:8000/temp.html would get rewritten as
http://location:8000/temp.html#/temp.html by error.
This fixes regression introduced by #3514 (5c560117) - this commit is being
reverted here and a better fix is included.
The regression caused the controller to be instantiated before the isolate scope
was initialized.
Closes#3493Closes#3482Closes#3537Closes#3540
BREAKING CHANGE: the `always` method has been renamed to `finally`.
The reason for this change is to align `$q` with the Q promises library,
despite the fact that this makes it a bit more difficult to
use with non-ES5 browsers, like IE8.
`finally` also goes well together with `catch` api that was added to
$q recently and is part of the DOM promises standard.
To migrate the code follow the example below:
Before:
$http.get('/foo').always(doSomething);
After:
$http.get('/foo').finally(doSomething);
or for IE8 compatible code:
$http.get('/foo')['finally'](doSomething);
To avoid "Argument type Array is not assignable to parameter type function" validation error When using the minifcation-safe array style
(eg .directive('myDirective', ['$http','$timeout','$compile', function($http,$timeout $compile).... )
Closes#3392
Controllers should be always instantiated after compile fn runs, but before
pre-link fn runs. This way, controllers are available to pre-link fns that
request them.
Previously this was broken for async directives (directives with templateUrl).
Closes#3493Closes#3482Closes#3514
<form name="ctrl.form"> form controller will accessible
as $scope.ctrl.form instead of $scope['ctrl.form']
BREAKING CHANGE:
If you have form names that will evaluate as an expression:
<form name="ctrl.form">
And if you are accessing the form from your controller:
Before:
function($scope) {
$scope['ctrl.form'] // form controller instance
}
After:
function($scope) {
$scope.ctrl.form // form controller instance
}
This makes it possible to access a form from a controller
using the new "controller as" syntax. Supporting the previous
behavior offers no benefit.
The input field email regex does't not match long domain extensions. This commit extends the email regexp to take a 6 character TLD.
Example 6-character TLDs include .museum and .travel - (e.g. allabout.travel).
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
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.
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 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
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.
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
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.
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
