This change gives us ~10% boost in Chrome, less or nothing in other browsers.
BREAKING CHANGE: `this` in filters is now undefined and no longer the scope
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 }}`
We no longer have a need for this feature that was added to primarily support
$watchGroup (see previous commit).
BREAKING CHANGE: deregisterNotifier callback for $watch is no longer available
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.
We no longer have a need for this feature that was added to primarily support
$watchGroup (see previous commit).
BREAKING CHANGE: deregisterNotifier callback for $watch is no longer available
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.
Chrome and FF are smart enough to notice that the key is is a string literal, so this change doesn't
make a difference there. Safari gets a boost. I haven't tested IE, but it can't cause harm there. :)
http://jsperf.com/fn-dereferencing
BEAKING CHANGE:
Lazy-binding now happens on the scope watcher level.
What this means is that given `parseFn = $parse('::foo')`,
bind-once will only kick in when `parseFn` is being watched by a scope
(i.e. `scope.$watch(parseFn)`)
Bind-once will have no effect when directily invoking `parseFn` (i.e. `parseFn()`)
BREAKING CHANGE:
You can no longer invoke .bind, .call or .apply on a function in angular expressions.
This is to disallow changing the behaviour of existing functions
in an unforseen fashion.
__proto__ can be used to mess with global prototypes and it's
deprecated. Therefore, blacklisting it seems like a good idea.
BREAKING CHANGE:
The (deprecated) __proto__ propery does not work inside angular expressions
anymore.
It was possible to use `{}.__defineGetter__.call(null, 'alert', (0).valueOf.bind(0))` to set
`window.alert` to a false-ish value, thereby breaking the `isWindow` check, which might lead
to arbitrary code execution in browsers that let you obtain the window object using Array methods.
Prevent that by blacklisting the nasty __{define,lookup}{Getter,Setter}__ properties.
BREAKING CHANGE:
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.
It was possible to run arbitrary JS from inside angular expressions using the
`Object.getOwnPropertyDescriptor` method like this since commit 4ab16aaa:
''.sub.call.call(
({})["constructor"].getOwnPropertyDescriptor(''.sub.__proto__, "constructor").value,
null,
"alert(1)"
)()
Fix that by blocking access to `Object` because `Object` isn't accessible
without tricks anyway and it provides some other nasty functions.
BREAKING CHANGE:
This prevents the use of `Object` inside angular expressions.
If you need Object.keys, make it accessible in the scope.
Expressions that start with `::` will be binded once. The rule
that binding follows is that the binding will take the first
not-undefined value at the end of a $digest cycle.
Watchers from $watch, $watchCollection and $watchGroup will
automatically stop watching when the expression(s) are bind-once
and fulfill.
Watchers from text and attributes interpolations will
automatically stop watching when the expressions are fulfill.
All directives that use $parse for expressions will automatically
work with bind-once expressions. E.g.
<div ng-bind="::foo"></div>
<li ng-repeat="item in ::items">{{::item.name}};</li>
Paired with: Caitlin and Igor
Design doc: https://docs.google.com/document/d/1fTqaaQYD2QE1rz-OywvRKFSpZirbWUPsnfaZaMq8fWI/edit#Closes#7486Closes#5408
The feature has been deprecated in #4317
BREAKING CHANGE: promise unwrapping has been removed.
It has been deprecated since 1.2.0-rc.3.
It can no longer be turned on.
Two methods have been removed:
* $parseProvider.unwrapPromises
* $parseProvider.logPromiseWarnings
Previously, constant numbers with a unary minus sign were not treated as constants. This fix corrects
this behaviour, and may provide a small performance boost for certain applications, due to constant
watches being automatically unregistered after their first listener call.
Closes#6932
Per ECMAScript 5.1 specification trailing commas are allowed in object and
array literals. All modern browsers as well as IE>8 support this syntax.
This commit adds support for such syntax to Angular expressions.
There are always going to be false positives here, unfortunately. But
testing different properties will hopefully reduce the number of false
positives in a meaningful way, without harming performance too much.
Closes#4805Closes#5675
cspSafeGetterFn incorrectly returned undefined if any of its key parameters were undefined. This
wasn't caught by the $parse unit tests because of a timing problem where $ParseProvider was reading
the CSP flag before the tests manually set it, so the CSP property evaluation tests never ran. Add
test that verifies evaluation of nested properties of multiple lengths.
Closes#5591Closes#5592
Prior to this fix, $parse/$eval would return 'null' if a middle key in
an expression's value is null, when it should be expected to be undefined.
This patch tries to remedy this by returning undefined for middle values in
expressions, when fetching a child of that null value.
For example:
```js
// Given the following object:
$scope.a = {
b: null
};
// $scope.$eval('a.b.c') returns undefined, whereas previously it would return null
```
Closes#5480
