angular.js/test, branch v1.2.2 fix($httpBackend): only IE8 and below can't use `script.onload` for JSONP 2013-11-22T13:45:55+00:00 Pete Bacon Darwin 2013-11-22T13:22:41+00:00 a3172a285fd74b5aa6c8d68a4988c767c06f549c IE8, IE9 and IE10 can use `script.onreadystate` so up till now we have been using this if the sniffer says we are on IE. But IE11 now does not support `script.onreadystate` and only supports the more standard `script.onload` and `script.onerror`. IE9 and IE10 do support `script.onload` and `script.onerror`. So now we only test whether we are on IE8 or earlier before using `script.onreadystate`. See http://pieisgood.org/test/script-link-events/ jQuery just uses all these handlers at once and hopes for the best, but since IE9 and IE10 support both sets of handlers, this could cause the handlers to be run more than once. jQuery also notes that there is a potential memory leak in IE unless we remove the handlers from the script object once they are run. So we are doing this too, now. Closes #4523 Closes #4527 Closes #4922 
IE8, IE9 and IE10 can use `script.onreadystate` so up till now we have been using this
if the sniffer says we are on IE.
But IE11 now does not support `script.onreadystate` and only supports the more standard
`script.onload` and `script.onerror`.
IE9 and IE10 do support `script.onload` and `script.onerror`. So now we only test whether
we are on IE8 or earlier before using `script.onreadystate`.
See http://pieisgood.org/test/script-link-events/

jQuery just uses all these handlers at once and hopes for the best, but since IE9 and IE10
support both sets of handlers, this could cause the handlers to be run more than once.

jQuery also notes that there is a potential memory leak in IE unless we remove the handlers
from the script object once they are run.  So we are doing this too, now.

Closes #4523
Closes #4527
Closes #4922
test($compile): correct the assertion to make test pass on IE11 2013-11-22T08:52:57+00:00 Igor Minar 2013-11-22T08:52:57+00:00 84c408ce63859e81fb4e900683edcc0cb8188890 






fix($parse): allow for new lines in expr when promise unwrapping is on
2013-11-22T08:19:08+00:00

rodyhaddad

2013-10-30T19:14:00+00:00

40647b179c473f3f470bb1b3237d6f006269582f

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





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







fix($compile): secure form[action] & iframe[srcdoc]
2013-11-22T07:15:15+00:00

Chirayu Krishnappa

2013-11-12T23:32:52+00:00

0421cb4200e672818ed10996e92311404c150c3a

Require bindings to form[action] to be $sce.RESOURCE_URL and bindings to
iframe[srcdoc] to be $sce.HTML

Closes #4927
Closes #4933





Require bindings to form[action] to be $sce.RESOURCE_URL and bindings to
iframe[srcdoc] to be $sce.HTML

Closes #4927
Closes #4933







fix(httpBackend): should not read response data when request is aborted
2013-11-22T07:09:46+00:00

Gonzalo Ruiz de Villa

2013-11-13T20:24:15+00:00

6f1050df4fa885bd59ce85adbef7350ea93911a3

When a request is aborted, it makes no sense to read the response headers or text.
Also in IE9, trying to read data (either response headers or text) from an aborted request
throws an Error c00c023f.

Fixes #4913
Closes #4940





When a request is aborted, it makes no sense to read the response headers or text.
Also in IE9, trying to read data (either response headers or text) from an aborted request
throws an Error c00c023f.

Fixes #4913
Closes #4940







fix(ngMock): fixes httpBackend expectation with body object
2013-11-22T06:57:15+00:00

Corey Burrows

2013-11-14T14:42:35+00:00

4d16472b918a3482942d76f1e273a5aa01f65e83

Fixes an issue with httpBackend expectations where a given body object
may not match the actual request body if its keys are serialized in a
different order.

Closes #4956





Fixes an issue with httpBackend expectations where a given body object
may not match the actual request body if its keys are serialized in a
different order.

Closes #4956







fix(loader): expose `$$minErr` to modules such as`ngResource`
2013-11-22T06:51:26+00:00

Pete Bacon Darwin

2013-11-20T10:35:27+00:00

9e89a31b129e40c805178535c244899ffafb77d8

This is highlighted in angular-phonecat when you try to use the index-async.html
which needs to load the ngResource module asynchronously but fails when it tries
to call `angular.$$minErr` to create the $resourceMinErr object.

Closes #5050





This is highlighted in angular-phonecat when you try to use the index-async.html
which needs to load the ngResource module asynchronously but fails when it tries
to call `angular.$$minErr` to create the $resourceMinErr object.

Closes #5050







fix(ngView): Don't throw when the ngView element contains content with directives.
2013-11-22T06:20:11+00:00

Tobias Bosch

2013-11-22T05:54:59+00:00

e6521e7491242504250b57dd0ee66af49e653c33

Fixes #5069





Fixes #5069







fix(ngInclude): Don't throw when the ngInclude element contains content with directives.
2013-11-22T06:20:11+00:00

Tobias Bosch

2013-11-22T05:54:42+00:00

0a7cbb33b06778833a4d99b1868cc07690a827a7

Related to #5069





Related to #5069







fix(tests): Correct tests for IE11
2013-11-22T05:53:09+00:00

Tobias Bosch

2013-11-21T22:30:50+00:00

579242346c4202ea58fc2cae6df232289cbea0bb

Some tests were wrong. However, src/* did not contain problems.

Fixes #5046





Some tests were wrong. However, src/* did not contain problems.

Fixes #5046