| Age | Commit message (Collapse) | Author |
|---|
|
Closes #6502
|
|
Closes #5759
The default trusted origin appears to be the same protocol+domain+port,
non just protocol+domain.
I patched the doc accordingly.
|
|
Mention common cause of error is binding to a new array on every $digest loop.
Closes #6465
|
|
|
|
|
|
|
|
It is safer to use markdown style links and save jsdoc style links for
internal links and code references
|
|
window.XMLHttpRequest is not always available in IE8 despite it not running in quirks mode,
in which case Angular should be using the ActiveXObject instead. Just checking the browser
version is taking too many shortcuts.
Closes #5677
Closes #5679
|
|
correcting directive name to ng-model instead of ng-mode in nodomevents.ngdoc
Correcting use of ng-model directive
Closes #6036
|
|
IE8's native XHR doesn't support PATCH requests, but the ActiveX one does.
I'm also removing the noxhr error doc because nobody will ever get that error.
Closes #2518
Closes #5043
|
|
Closes #5610
|
|
Closes #5313
|
|
Closes #5259
|
|
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
|
|
HTML elements were getting parsed by as HTML elements
Closes #4827
|
|
params and paramDefaults support looking up the parameter value from the
data object. The syntax for that is `@nested.property.name`.
Currently, $resource uses $parse to do this. This is too liberal
(you can use values like `@a=b` or `@a | filter` and have it work -
which doesn't really make sense). It also puts up a dependency on
$parse which is has restrictions to secure expressions used in
templates. The value here, though a string, is specified in Javascript
code and shouldn't have those restrictions.
|
|
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 #4503
|
|
It is instructive to give literal examples that reflect common (my) experience of the problem. :)
|
|
Closes #4449
|
|
Closes #4418
|
|
|
|
This also contains some whitespace corrections by my editor.
|
|
|
|
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
|
|
Closes #4006
|
|
Closes #3759
|
|
|
|
|
|
|
|
Closes #3568
|
|
|
|
|
|
|
|
we can never get to this state, so dropping the error
|
|
Closes #3527
|
|
Nothing would prevent a user from accidentally calling angular.bootstrap on an element that had already been bootstrapped. If this was done, odd behavior could manifest in an application, causing different scopes to update the same DOM, and causing debugger confusion.
This fix adds a check inside of angular.bootstrap to check if the passed-in element already has an injector, and if so, will throw an error.
|
|
|
|
Closes #3459
|
|
Closes #3459
|
|
Closes #3459
|
|
Closes #3459
|
|
Closes #3459
|
|
|
|
|
|
|
|
|
|
|
|
Closes #3510
|
