angular.js/docs/content/error, branch v1.2.11 fix($http): update httpBackend to use ActiveXObject on IE8 if necessary 2014-02-01T00:52:42+00:00 Jorg 2014-01-08T01:23:33+00:00 ef210e5e119db4f5bfc9d2428b19f9b335c4f976 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 
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
docs(compile/nodomevents): fix typo ng-mode -> ng-model 2014-01-29T13:51:02+00:00 Manan 2014-01-29T06:33:15+00:00 7a78aed1603ca7f60f2f70ba27f0102e08862550 correcting directive name to ng-model instead of ng-mode in nodomevents.ngdoc Correcting use of ng-model directive Closes #6036 
correcting directive name to ng-model instead of ng-mode in nodomevents.ngdoc

Correcting use of ng-model directive

Closes #6036
fix($httpBackend): use ActiveX XHR when making PATCH requests on IE8 2014-01-03T06:04:32+00:00 Igor Minar 2013-12-13T09:49:37+00:00 6c17d02bc4cc02f478775d62e1f9f77da9da82ad 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 
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
docs(error/ngRepeat/dupes): fix typo 2014-01-03T05:34:34+00:00 Drew Perttula 2014-01-03T05:18:02+00:00 6a6f71f238d2603cbc286ba29ec7503ad45f7f20 Closes #5610 
Closes #5610
docs(error/noregexp): fix link to ng-pattern 2013-12-18T21:14:10+00:00 Ziang Song 2013-12-06T18:56:20+00:00 41534816a4873b71913c936e17692931a07e3a85 Closes #5313 
Closes #5313
docs(error/transclude/orphan): fix spelling mistakes 2013-12-12T11:15:31+00:00 Mattias Holmlund 2013-12-04T10:17:15+00:00 4ac21ac039c3aa274904e8fcaab6622f8a1ccf84 Closes #5259 
Closes #5259
feat($parse): revert hiding "private" properties 2013-11-14T07:25:09+00:00 Vojta Jina 2013-11-14T07:25:09+00:00 4ab16aaaf762e9038803da1f967ac8cb6650727d 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 
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
docs(errors/compile/tplrt): display html block as code 2013-11-13T21:06:37+00:00 Eddie Monge Jr 2013-11-07T21:57:00+00:00 a59976be18585033b29a9f323477f1194b53d3d7 HTML elements were getting parsed by as HTML elements Closes #4827 
HTML elements were getting parsed by as HTML elements

Closes #4827
fix($resource): don't use $parse for @dotted.member 2013-11-12T00:17:34+00:00 Chirayu Krishnappa 2013-11-09T04:44:32+00:00 9577702e8d2519c1a60f5ac4058e63bd7b919815 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. 
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.
feat($parse): secure expressions by hiding "private" properties 2013-10-31T00:01:51+00:00 Chirayu Krishnappa 2013-10-18T02:44:36+00:00 3d6a89e8888b14ae5cb5640464e12b7811853c7e 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. 
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.