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 3d6a89e888.
Closes#4926Closes#4842Closes#4865Closes#4859Closes#4849
Conflicts:
src/ng/parse.js
Prior to this fix, the urlResolve method would automatically
strip the first segment of a path if the segment ends in a colon.
This was to correct undesired behavior in the $location service
using the file protocol on windows in multiple browsers (see #4680).
However, there could be cases where users intentionally
have first path segments that end in a colon
(although this conflicts with section 3.3 of rfc3986).
The solution to this problem is an extra check to make sure
the first path segment of the input url does not end with a colon,
to make sure we're only removing undesired path segments.
Fixes#4939
Chrome and other browsers on Windows often
append the drive name to the pathname,
as described in #4680. This would cause
the location service to browse to odd
URLs, such as /C:/myfile.html,
when opening apps using file://.
Fixes #4680
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.
See doc update in the diff for more info.
BREAKING CHANGE: jqLite#scope() does not return the isolate scope on the element
that triggered directive with isolate scope. Use jqLite#isolateScope() instead.
When an isolate scope directive is also a "replace" directive and at the root of its template
it has other directives, we need to keep track remember to use isolate scope when linking
these.
This commit fixes the leakage of this state when this directive is used again later inside
or outside of the isolate directive template.
Fixes an issue when we didn't share the isolate scope with the controller
of the directive from the isolate directive's template when this directive
was replaced onto the isolate directive element.
I had to fix one unit test, as it assumed the broken behavior, where application template gets the
isolate scope of other (isolate) directive, rather than the regular scope.
BREAKING CHANGE: Child elements that are defined either in the application template or in some other
directives template do not get the isolate scope. In theory, nobody should rely on this behavior, as
it is very rare - in most cases the isolate directive has a template.
Fixes issue with isolate scope leaking all over the place into other directives on the same element.
Isolate scope is now available only to the isolate directive that requested it and its template.
A non-isolate directive should not get the isolate scope of an isolate directive on the same element,
instead they will receive the original scope (which is the parent scope of the newly created isolate scope).
Paired with Tobias.
BREAKING CHANGE: Directives without isolate scope do not get the isolate scope from an isolate directive on the same element. If your code depends on this behavior (non-isolate directive needs to access state from within the isolate scope), change the isolate directive to use scope locals to pass these explicitly.
// before
<input ng-model="$parent.value" ng-isolate>
.directive('ngIsolate', function() {
return {
scope: {},
template: '{{value}}'
};
});
// after
<input ng-model="value" ng-isolate>
.directive('ngIsolate', function() {
return {
scope: {value: '=ngModel'},
template: '{{value}}
};
});
Closes#1924Closes#2500
We need to wait until animations have added the content to the document before
trying to `autoscroll` to anchors that may have been inserted.
Fixes#4723
BREAKING CHANGE
ngAnimate addClass / removeClass animations are now applied right away. This means
that as soon as the animation starts the class will be added (addClass) or removed
(removeClass) to the element being animated instead of after the -add-active /
-remove-active animations are completed. This allows for animations outside of
ngAnimate to not conflict with $animate.
This commit introduces beforeAddClass and beforeRemoveClass animation event functions and
executes any addClass and removeClass event functions AFTER the class has been added or
removed (this is opposite functionality of how ngAnimate used to work when performing
JS-enabled animations addClass / removeClass animations). If your animation code relies on
any animations being performed prior to the class change then simply use the new
beforeAddClass and beforeRemoveClass animation event functions.
Finally, when animating show and hide animations using CSS transitions or keyframe animations,
ng-hide-remove doesn't require `display:block!important` for ng-hide-add anymore.
The msie variable is a global variable used within the ng core which contains the
version number for the current Internet Explorer browser that is rendering the
application. Other modules outside of the ng core could make use of this variable
instead of having to rollout duplicate detection code. This code makes it easy to
reuse this simple property within the $sniffer service.
Due to animations, DOM might get destroyed much later than scope and so the element $destroy event
might get fired outside of $digest, which causes changes to the validation model go unobserved
until the next digest. By deregistering on scope event, the deregistration always happens
in $digest and the form validation model changes will be observed.
Closes#4226Closes#4779
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.
When using ngIf with ngInclude on the same element, ngIf previously did not remove
elements added by ngInclude. Similarly, when using ngIfStart/End, ngIf will miss
elements added between the start/end markers added after ngIf is linked.
This commit changes the behavior of ngIf to add a comment node at the end of its
elements such that elements between the starting comment and this ending comment
are removed when ngIf's predicate does not hold.
Recently we changed the priority of attribute interpolation directive to -100
to ensure that it executes early in the post linking phase. This causes issues
with when terminal directives are placed on elements with attribute bindings
because the terminal directive will usually have 0 or higher priority which
results in attr interpolation directive not being applied to the element.
To fix this issue I'm switching the priority back to 100 and making moving the
binding setup into the pre-linking function.
This means that:
- terminal directives with priority lower than 100 will not affect the attribute
binding
- if a directive wants to add or alter bindings it can do so in the pre-linking
phase, as long as the priority of this directive is more than 100
- all post-linking functions will execute after the attribute binding has been
set up
- all pre-linking functions with directive priority lower than 100 will execute
after the attribute bindings have been setup
BREAKING CHANGE: the attribute interpolation (binding) executes as a directive
with priority 100 and the binding is set up in the pre-linking phase. It used
to be that the priority was -100 in rc.2 (100 before rc.2) and that the binding
was setup in the post-linking phase.
Closes#4525Closes#4528Closes#4649
Skip addClass animations if the element already contains the class that is being
added to element. Also skip removeClass animations if the element does not contain
the class that is being removed.
Closes#4401Closes#2332
When we re-enter compilation either due to async directive templates or element transclude directive
we need to keep track of controllers to instantiate during linking.
This piece of info was missing when re-entering compilation and that's what this commit fixes.
I also reordered the properties in the previousCompileContext object.
Closes#4434Closes#4616
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.
Issue an error and abort compilation when two directives that ask for transclusion are found
on a single element. This configuration is not supported and we previously failed to issue
the error because in the case of element transclusion the compilation is re-started and this
caused the compilation context to be lost.
The ngRepeat directive has been special-cased to bypass this warning because it knows how to
handle this scenario internally.
This is not an ideal solution to the problem of multiple transclusions per element, we are
hoping to have this configuration supported by the compiler in the future. See #4357.
Closes#3893Closes#4217Closes#3307
