| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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 #4805
Closes #5675
|
|
Do not use the locals when performing a field access in an angular expression.
Closes #5838
Closes #5862
|
|
its tests from failing
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 #5591
Closes #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
|
|
Use a faster path when the number of path tokens is low (ie the common case).
This results in a better than 19x improvement in the time spent in $parse and
produces output that is about the same speed in chrome and substantially faster
in firefox.
http://jsperf.com/angularjs-parse-getter/6
Closes #5359
|
|
Previously, when unwrapping promises was set to `true`,
an error would occur if a parsed expression had a
new line in it.
This was because when generating the `evaledFnGetter` code,
a new line in an parsed expression would create a new line
in a JS string in that code, which is illegal. That is:
```js
pw("A+
B")
```
Closes #4718
|
|
Hiding `_*` properties was a feature primarily for developers using Closure compiler and Google JS
style. We didn't realize how many people will be affected by this change.
We might introduce this feature in the future, probably under a config option, but it needs more
research and so I'm reverting the change for now.
This reverts commit 3d6a89e8888b14ae5cb5640464e12b7811853c7e.
Closes #4926
Closes #4842
Closes #4865
Closes #4859
Closes #4849
Conflicts:
src/ng/parse.js
|
|
BREAKING CHANGE:
This commit introduces the notion of "private" properties (properties
whose names begin and/or end with an underscore) on the scope chain.
These properties will not be available to Angular expressions (i.e. {{
}} interpolation in templates and strings passed to `$parse`) They are
freely available to JavaScript code (as before).
Motivation
----------
Angular expressions execute in a limited context. They do not have
direct access to the global scope, Window, Document or the Function
constructor. However, they have direct access to names/properties on
the scope chain. It has been a long standing best practice to keep
sensitive APIs outside of the scope chain (in a closure or your
controller.) That's easier said that done for two reasons: (1)
JavaScript does not have a notion of private properties so if you need
someone on the scope chain for JavaScript use, you also expose it to
Angular expressions, and (2) the new "controller as" syntax that's now
in increased usage exposes the entire controller on the scope chain
greatly increaing the exposed surface. Though Angular expressions are
written and controlled by the developer, they (1) typically deal with
user input and (2) don't get the kind of test coverage that JavaScript
code would. This commit provides a way, via a naming convention, to
allow publishing/restricting properties from controllers/scopes to
Angular expressions enabling one to only expose those properties that
are actually needed by the expressions.
|
|
Closes #4417
|
|
This reverts commit 3a65822023119b71deab5e298c7ef2de204caa13.
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 #4158
Closes #4270
|
|
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-changes
Closes #3681
|
|
|
|
|
|
When a parsed function call returns a promise, the evaluated value
is the resolved value of the promise rather than the promise object.
Closes #3503
|
|
Closes #3566
|
|
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
|
|
Enhances sandboxing of Angular Expressions to prevent attacks via:
{}.toString.constructor(alert("evil JS code"))
|
|
|
|
- add toThrowNg matcher
|
|
|
|
Add '?' token to lexer, add ternary rule to parser at
(hopefully) proper precedence and associativity (based
on https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Operators/Operator_Precedence).
Since (exp1 && exp2 || exp3) is supported by the parser,
and (exp1 ? exp2 : exp3) works the same way, it seems
reasonable to add this minor form of control to templates
(see #719).
|
|
New tests to not call twice a function to get self
|
|
* `literal` is set to true if the expression's top-level is a JavaScript
literal (number, string, boolean, null/undefined, array, object), even
if it contains non-literals inside.
* `constant` is set to true if the expression is known to be made
entirely of constant values, i.e., evaluating it will always yield the
same result.
A consequence is that a JSON expression is guaranteed to be both literal
and constant.
|
|
Allows the parser to parse strict equality and inequality
in angular expressions.
Closes #908
|
|
e.g. zero, false, empty string
- fix tests to be executed with csp true
- fix cps (when more than 5 parts)
|
|
CSP (content security policy) forbids apps to use eval or
Function(string) generated functions (among other things). For us to be
compatible, we just need to implement the "getterFn" in $parse without
violating any of these restrictions.
We currently use Function(string) generated functions as a speed
optimization. With this change, it will be possible to opt into the CSP
compatible mode using the ngCsp directive. When this mode is on Angular
will evaluate all expressions up to 30% slower than in non-CSP mode, but
no security violations will be raised.
In order to use this feature put ngCsp directive on the root element of
the application. For example:
<!doctype html>
<html ng-app ng-csp>
...
...
</html>
Closes #893
|
|
|
