angular.js/src/ng, branch v1.2.3 refactor($location): move file://+win path fix to $location 2013-11-27T02:31:27+00:00 Jeff Cross 2013-11-26T19:36:36+00:00 736c8fbbae57a209f4ba570e38cc3bd0745a9569 The urlResolve method was fixed to automatically remove the volume label from path names to fix issues with the file protocol on windows where $location.path() was returning paths where the first segment would be the volume name, such as "/C:/mypath". See #4942 and #4928 However, the solution was specific to the $location non- HTML5 mode, and was implemented at a lower level of abstraction than it should have been. This refactor moves the fix to inside of the LocationHashBangUrl $$parse method. Closes #5041 
The urlResolve method was fixed to automatically remove the
volume label from path names to fix issues with the file
protocol on windows where $location.path() was returning
paths where the first segment would be the volume name,
such as "/C:/mypath". See #4942 and #4928

However, the solution was specific to the $location non-
HTML5 mode, and was implemented at a lower level of
abstraction than it should have been. This refactor moves
the fix to inside of the LocationHashBangUrl $$parse method.

Closes #5041
fix($sanitize): Use same whitelist mechanism as $compile does. 2013-11-26T22:29:38+00:00 Tobias Bosch 2013-11-25T23:40:18+00:00 333523483f3ce6dd3177b697a5e5a7177ca364c8 `$sanitize` now uses the same mechanism as `$compile` to validate uris. By this, the validation in `$sanitize` is more general and can be configured in the same way as the one in `$compile`. Changes - Creates the new private service `$$sanitizeUri`. - Moves related specs from `compileSpec.js` into `sanitizeUriSpec.js`. - Refactors the `linky` filter to be less dependent on `$sanitize` internal functions. Fixes #3748. 
`$sanitize` now uses the same mechanism as `$compile` to validate uris.
By this, the validation in `$sanitize` is more general and can be
configured in the same way as the one in `$compile`.

Changes
- Creates the new private service `$$sanitizeUri`.
- Moves related specs from `compileSpec.js` into `sanitizeUriSpec.js`.
- Refactors the `linky` filter to be less dependent on `$sanitize`
  internal functions.

Fixes #3748.
chore($httpBackend): preserve original non-zero http status code for file:// apps 2013-11-26T20:36:41+00:00 corrupt 2013-10-18T12:42:55+00:00 68ceb17272bdd2ebc838565070973d93704f4427 Previously if an app was running from file:// origin we would always return either http 200 or 404 depending on whether the response was present. This changes the behavior so that we do this only if the protocol of the request (not the origin) is file:// and only if the status code is 0. Closes #4436 Closes #4587 Closes #4514 
Previously if an app was running from file:// origin we would always return either
http 200 or 404 depending on whether the response was present.

This changes the behavior so that we do this only if the protocol of the request
(not the origin) is file:// and only if the status code is 0.

Closes #4436
Closes #4587
Closes #4514
docs(compile): fix typo 2013-11-26T06:56:38+00:00 adam77 2013-11-25T22:44:34+00:00 e8d8c7a8d773ec662c3d005bc434f356f96fd807 Closes #5133 
Closes #5133
fix(input): Support form auto complete on modern browser 2013-11-23T01:02:21+00:00 Tobias Bosch 2013-11-23T00:34:33+00:00 a090400f09d7993d102f527609879cdc74abae60 Although modern browser support the "input" event, they still only fire the "change" event when they auto complete form elements other than the currently selected one. Related to #1460 
Although modern browser support the "input" event, they still only fire
the "change" event when they auto complete form elements
other than the currently selected one.

Related to #1460
chore(style): fix missing indentation in httpBackend from a3172a2 2013-11-22T15:03:12+00:00 Caitlin Potter 2013-11-22T13:57:13+00:00 0f7c4ca671ac807c53510372bb24d5cfec0bc7f5 






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







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