Remove support for bootstrap detection using:
* The element id
* The element class.
E.g.
```
<div id="ng-app">...</div>
<div class="ng-app: module">...</div>
```
Removes reference to how to bootstrap using IE7
BREAKING CHANGE:
If using any of the mechanisms specified above, then migrate by
specifying the attribute `ng-app` to the root element. E.g.
```
<div ng-app="module">...</div>
```
Closes#8147
CSP spec got changed and it is no longer possible to autodetect if a policy is
active without triggering a CSP error:
18882953ce
Now we use `new Function('')` to detect if CSP is on. To prevent error from this
detection to show up in console developers have to use the ngCsp directive.
(This problem became more severe after our recent removal of `simpleGetterFn`
which made us depend on function constructor for all expressions.)
Closes#8162Closes#8191
Previously, properties (typically functions) in the prototype chain (Object.prototype) would shadow
query parameters, and cause them to be serialized incorrectly.
This CL guards against this by using hasOwnProperty() to ensure that only own properties are a concern.
Closes#8070Fixes#8068
So far, angular.copy was copying all properties including those from
prototype chain and was losing the whole prototype chain (except for Date,
Regexp, and Array).
Deep copy should exclude properties from the prototype chain because it
is useless to do so. When modified, properties from prototype chain are
overwritten on the object itself and will be deeply copied then.
Moreover, preserving prototype chain allows instanceof operator to be
consistent between the source object and the copy.
Before this change,
var Foo = function() {};
var foo = new Foo();
var fooCopy = angular.copy(foo);
foo instanceof Foo; // => true
fooCopy instanceof Foo; // => false
Now,
foo instanceof Foo; // => true
fooCopy instanceof Foo; // => true
The new behaviour is useful when using $http transformResponse. When
receiving JSON data, we could transform it and instantiate real object
"types" from it. The transformed response is always copied by Angular.
The old behaviour was losing the whole prototype chain and broke all
"types" from third-party libraries depending on instanceof.
Closes#5063Closes#3767Closes#4996
BREAKING CHANGE:
This changes `angular.copy` so that it applies the prototype of the original
object to the copied object. Previously, `angular.copy` would copy properties
of the original object's prototype chain directly onto the copied object.
This means that if you iterate over only the copied object's `hasOwnProperty`
properties, it will no longer contain the properties from the prototype.
This is actually much more reasonable behaviour and it is unlikely that
applications are actually relying on this.
If this behaviour is relied upon, in an app, then one should simply iterate
over all the properties on the object (and its inherited properties) and
not filter them with `hasOwnProperty`.
**Be aware that this change also uses a feature that is not compatible with
IE8.** If you need this to work on IE8 then you would need to provide a polyfill
for `Object.create` and `Object.getPrototypeOf`.
In apps that create lots of scopes (apps with large tables) the uid generation
shows up in the profiler and adds a few milliseconds. Using simple counter
doesn't have this overhead.
I think the initial fear of overflowing and thus using string alphanum sequence
is unjustified because even if an app was to create lots of scopes non-stop,
you could create about 28.6 million scopes per seconds for 10 years before
you would reach a number that can't be accurately represented in JS
BREAKING CHANGE: Scope#$id is now of time number rather than string. Since the
id is primarily being used for debugging purposes this change should not affect
anyone.
This modifies the injector to prevent automatic annotation from occurring for a given injector.
This behaviour can be enabled when bootstrapping the application by using the attribute
"ng-strict-di" on the root element (the element containing "ng-app"), or alternatively by passing
an object with the property "strictDi" set to "true" in angular.bootstrap, when bootstrapping
manually.
JS example:
angular.module("name", ["dependencies", "otherdeps"])
.provider("$willBreak", function() {
this.$get = function($rootScope) {
};
})
.run(["$willBreak", function($willBreak) {
// This block will never run because the noMagic flag was set to true,
// and the $willBreak '$get' function does not have an explicit
// annotation.
}]);
angular.bootstrap(document, ["name"], {
strictDi: true
});
HTML:
<html ng-app="name" ng-strict-di>
<!-- ... -->
</html>
This will only affect functions with an arity greater than 0, and without an $inject property.
Closes#6719Closes#6717Closes#4504Closes#6069Closes#3611
ngResource no longer filters properties prefixed with a single "$" character from requests or
responses, correcting a regression introduced in 1.2.6 (cb29632a) which caused shallowCopy and
shallowClearAndCopy to ignore properties prefixed with a single "$".
Closes#5666Closes#6080Closes#6033
In IE8 the result object
of calling `node.querySelectorAll` does not have a `hasOwnPropery`
function. However, it should be usable with `forEach`.
Related to #5400.
angular.isElement currently returns a truthy object/function, or false. This
patch aims to correct this behaviour by casting the result of the isElement
expression to a boolean value via double-negation.
Closes#4519Closes#4534
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.
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
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
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.
angular.copy previously copied RegExp as an empty object. Change detects
RegExp instance and clones into new RegExp. This change is based on a previous
fix to allow Date to be copied.
Closes#3473Closes#3474
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.
Regular expression objects didn't used to be considered to be equal when using
'angular.equals'. Dirty checking therefore failed to recognize a
property modification.
Closes#2685
Return early in `angular.toJson` if the object to be stringified is `undefined`.
IE8 stringifies `undefined` to `'undefined'` whereas other browsers return
`undefined`. This normalizes behavior and passes currently broken unit tests
in IE8.
Merely testing for object[key] will give incorrect results on keys
defined in Object.prototype.
Note: IE8 is generally broken in this regard since `for...in` never returns
certain property keys even if they are defined directly on the object.
See #2141 - partially merges this PR
parseKeyValue and toKeyValue can now handle duplicate values in the query.
```
?x=1&x=2 <-> {x:[1,2]}
```
The algorithm looks like:
1)parseKeyValue looks for presence of obj[key]
2)detects and replaces obj[key] with [obj[key],val]
3)then pushes more duplicates if necessary
4)toKeyValue decodes array correctly
5)(not changed)$location.search({param: 'key'}) still replaces if necessary
6)(not changed)$location.search({param: ['key1', 'key2']}) sets the url with duplicates
BREAKING CHANGE: Before this change:
- `parseKeyValue` only took the last key overwriting all the previous keys;
- `toKeyValue` joined the keys together in a comma delimited string.
This was deemed buggy behavior. If your server relied on this behavior
then either the server should be fixed or a simple serialization of
the array should be done on the client before passing it to $location.
Copying the $$hashKey as part of copy/extend operations makes little
sense since hashkey is used primarily as an object id, especially in
the context of the ngRepeat directive. This change maintains the
existing $$hashKey of an object that is being copied into (likewise for
extend).
It is not uncommon to take an item in a collection, copy it,
and then append it to the collection. By copying the $$hashKey, this
leads to duplicate object errors with the current ngRepeat.
Closes#1875
This features enables tools like Batarang and test runners to
hook into angular's bootstrap process and sneak in more modules
into the DI registry which can replace or augment DI services for
the purpose of instrumentation or mocking out heavy dependencies.
If window.name contains prefix NG_DEFER_BOOTSTRAP! when
angular.bootstrap is called, the bootstrap process will be paused
until angular.resumeBootstrap is called.
angular.resumeBootstrap takes an optional array of modules that
should be added to the original list of modules that the app was
about to be bootstrapped with.
Should handle JQLite, jQuery, NodeList and other objects like arrays
but not other generic objects or instances of user defined types
with length property.
Closes#1840
in 5ae63fd3 the comparison was made consistent but strict, so that
angular.equals({}, {foo: undefined}) // always returns false
this turns out to cause issues for data that is being roundtripped via network
and serialized via JSON because JSON.stringify serializes {foo: undefined} as {}.
Since angular.equals() behaved like this before the 5ae63fd3 in 50% of the cases,
changing the behavior in this way should not introduce any significant issues.
Closes#1648
previously:
a = {};
b = {x:undefined};
angular.equals(a, b) == angular.equals(b, a) // returns false.
both should return false because these objects are not equal.
unlike in implemented in #1695 the comparison should be stricter
and return false not true. if we need to relax this in the future
we can always do so.
Closes#1648
