angular.js/src/ngSanitize, branch v1.2.9 fix($sanitize): consider `size` attribute as valid/allowed attribute 2013-12-28T00:22:35+00:00 Brady Isom 2013-12-23T20:13:41+00:00 056c8493521988dbb330c6636135b505737da918 The "size" attribute gets set on <font> elements when using HTML5 rich text editors, or elements with the contenteditable attribute, that rely on the 'fontSize' command (execCommand). Closes #5522 
The "size" attribute gets set on <font> elements when using HTML5 rich
text editors, or elements with the contenteditable attribute, that rely
on the 'fontSize' command (execCommand).

Closes #5522
fix(ngSanitize): prefer textContent to innerText to avoid layout trashing 2013-12-03T22:45:30+00:00 Michał Gołębiowski 2013-11-24T20:13:51+00:00 bf1972dc1e8ffbeaddfa53df1d49bc5a2177f09c innerText depends on styling as it doesn't display hidden elements. Therefore, it's better to use textContent not to cause unnecessary reflows. However, IE<9 don't support textContent so the innerText fallback is necessary. 
innerText depends on styling as it doesn't display hidden elements.
Therefore, it's better to use textContent not to cause unnecessary
reflows. However, IE<9 don't support textContent so the innerText
fallback is necessary.
fix($sanitize): don't rely on YARR regex engine executing immediately 2013-12-03T13:35:09+00:00 Pete Bacon Darwin 2013-12-03T10:39:09+00:00 81b81856ee43d2876927c4e1f774affa87e99707 In Safari 7 (and other browsers potentially using the latest YARR JIT library) regular expressions are not always executed immediately that they are called. The regex is only evaluated (lazily) when you first access properties on the `matches` result object returned from the regex call. In the case of `decodeEntities()`, we were updating this returned object, `parts[0] = ''`, before accessing it, `if (parts[2])', and so our change was overwritten by the result of executing the regex. The solution here is not to modify the match result object at all. We only need to make use of the three match results directly in code. Developers should be aware, in the future, when using regex, to read from the result object before making modifications to it. There is no additional test committed here, because when run against Safari 7, this bug caused numerous specs to fail, which are all fixed by this commit. Closes #5193 Closes #5192 
In Safari 7 (and other browsers potentially using the latest YARR JIT library)
regular expressions are not always executed immediately that they are called.
The regex is only evaluated (lazily) when you first access properties on the `matches`
result object returned from the regex call.

In the case of `decodeEntities()`, we were updating this returned object, `parts[0] = ''`,
before accessing it, `if (parts[2])', and so our change was overwritten by the result
of executing the regex.

The solution here is not to modify the match result object at all. We only need to make use
of the three match results directly in code.

Developers should be aware, in the future, when using regex, to read from the result object
before making modifications to it.

There is no additional test committed here, because when run against Safari 7, this
bug caused numerous specs to fail, which are all fixed by this commit.

Closes #5193
Closes #5192
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.
feat(docs): provide index pages for each angular module 2013-10-23T21:00:12+00:00 Matias Niemelä 2013-10-17T02:48:32+00:00 a7e12b7959212f2fa88fe17d5a045cc9d8b22922 






style: make jshint happy
2013-10-22T22:32:41+00:00

Vojta Jina

2013-10-22T21:41:21+00:00

f2fab498303e00d199cb3d19a008670e214d5c10












chore(grunt): add jshint tasks
2013-10-22T22:32:40+00:00

Pete Bacon Darwin

2013-10-21T08:06:53+00:00

934a95d3ef3f72dfc37b0b564624cb4a1286d4f4












fix($sanitize): sanitize DOCTYPE declarations correctly
2013-10-03T07:42:15+00:00

paolo-delmundo

2013-10-02T19:49:20+00:00

e66c23fe55f8571a014b0686c8dbca128e7a8240

HTML to be sanitized that contains a DOCTYPE declaration were causing
the HTML parser to throw an error.  Now the parser correctly removes
the declarations when sanitizing HTML.

Closes #3931





HTML to be sanitized that contains a DOCTYPE declaration were causing
the HTML parser to throw an error.  Now the parser correctly removes
the declarations when sanitizing HTML.

Closes #3931







fix(ngSanitize): sanitizer should not accept <!--> as a valid comment
2013-09-11T20:40:09+00:00

R. Merkert

2013-08-17T23:09:28+00:00

21e9e8cf68ef007136da6cc212d2f1f252fb668a

According to http://validator.w3.org/ , <!--> is not a valid comment
and neither is any comment containing the -- substring.





According to http://validator.w3.org/ , <!--> is not a valid comment
and neither is any comment containing the -- substring.







docs(module): improve the installation instructions for optional modules
2013-08-22T23:55:54+00:00

Brian Ford

2013-08-22T19:32:42+00:00

57c43dd3762ea665125bff7e4727bce06a225b32

Currently, the documentation does a bad job of explaining the distinction between the services that it provides,
and the module itself. Furthermore, the instructions for using optional modules are inconsistent or missing.
This commit addresses the problem by ading a new `{@installModule foo}` annotation to the docs generator that
inlines the appropriate instructions based on the name of the module.





Currently, the documentation does a bad job of explaining the distinction between the services that it provides,
and the module itself. Furthermore, the instructions for using optional modules are inconsistent or missing.
This commit addresses the problem by ading a new `{@installModule foo}` annotation to the docs generator that
inlines the appropriate instructions based on the name of the module.