| Age | Commit message (Collapse) | Author |
|---|
|
directives
Previously, classes added to asynchronous directive elements during the clone
attach function would not persist after the node is merged with the template, prior
to linking. This change corrects this behaviour and brings it in line with synchronous
directives.
Closes #5439
Closes #5617
|
|
protractor
Thanks to jeffbcross, petebacondarwin, btford, jdeboer, tbosch for contributions!
Closes #6023
|
|
Closes #5639
|
|
Closes #5599
|
|
It appears that this exceptional case was only valid for IE<8 and that for IE>=8 it
was actually causing a bug with the `ng-href-attr` directive on `<a>` elements.
Closes #5479
|
|
Add class ng-scope to dom nodes during directive compile rather than link.
Optimize handling of nodeLists.
This results in a savings of about 130ms during the startup of a product within Google.
Closes #5471
|
|
Closes #5310
|
|
jQuery's elem.html('') is way slower than elem.empty(). As clearing
element contents happens quite often in certain scenarios, switching
to using .empty() provides a significant performance boost when using
Angular with jQuery.
Closes #4457
|
|
When a component uses an isolate scope reference
and the the component is used with an object literal
a new object is created on every evaluation.
Therefore the compiler needs to compare
the values of the parent and the isolate scope
using object equality and not object reference
equality.
Fixes #5296.
|
|
If an element has a directive whose content is loaded using `templateUrl`,
and the element is cloned using a linking function before the template arrives,
the clone needs to be updated as well.
This also updates `ngIf` and `ngRepeat` to keep the connection to the clone
of a tranclude function, so that they know about the changes a directive with
`templateUrl` does to the element in the future.
Fixes to #4930.
|
|
When using two-way binding with isolate scope, under some circumstances
the lastValue variable captured in the parentValueWatch function can get
out of sync.
Specifically, if both the value in the origin scope as well as the value
in the isolate scope get independently updated to the same value within
one digest cycle, the lastValue is never updated. This potentially causes
the watch to make the wrong decision as to which side to update on subsequent
passes.
This fixes things by ensuring lastValue is always set to the last seen
value even if the watch's logic was short circuited because there was no
difference between the values in the original and isolate scopes.
Closes #5182
|
|
|
|
`$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.
|
|
Closes #5133
|
|
Require bindings to form[action] to be $sce.RESOURCE_URL and bindings to
iframe[srcdoc] to be $sce.HTML
Closes #4927
Closes #4933
|
|
When $compile interpolates a CSS class attribute expression it will
do so by comparing the CSS class value already present on the element.
This may lead to unexpected results when dealing with ngClass values being
added and removed therefore it is best that both compile and ngClass delegate
addClass/removeClass operations to the same block of code.
|
|
ngClass works by removing all the former classes and then adding all the
new classes to the element during each watch change operation. This may
cause transition animations to never render. The ngClass directive will
now only add and remove the classes that change during each watch operation.
Closes #4960
Closes #4944
|
|
Additional API (backwards compatible)
- Injects `$transclude` (see directive controllers) as 5th argument to directive link functions.
- `$transclude` takes an optional scope as first parameter that overrides the
bound scope.
Deprecations:
- `transclude` parameter of directive compile functions (use the new parameter for link functions instead).
Refactorings:
- Don't use comment node to temporarily store controllers
- `ngIf`, `ngRepeat`, ... now all use `$transclude`
Closes #4935.
|
|
|
|
Update the $compile docs to mention the change introduced in #4266.
Closes #4843
|
|
A directive with a template with `replace: true` and an interpolated style at the root element should work correctly.
Closes #4882.
|
|
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.
|
|
used multiple times
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.
|
|
|
|
isolate directive
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 #1924
Closes #2500
|
|
|
|
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.
|
|
directives
This is a fix for regression introduced last week by faf5b980.
Closes #4654
|
|
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 #4525
Closes #4528
Closes #4649
|
|
Closes #4589
|
|
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 #4434
Closes #4616
|
|
|
|
|
|
This also contains some whitespace corrections by my editor.
|
|
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 #3893
Closes #4217
Closes #3307
|
|
Array.prototype.sort is speced out to be as potentionally unstable sort,
which is how it's implemented in FF and IE. This has caused the order
of directives with the same priority to vary between browsers.
For consistency sake, we now consider directive name and registration,
order when determining the order of directives with the same priority.
Note: it is still possible to get into a situation when the directive
order is underministic - when source files are loaded asynchronously
in non-deterministic order and there are are directives registered
with the same name and priority, the order in which they will be applied
will depend on the file load order.
|
|
|
|
The location service, and other portions of the application,
were relying on a complicated regular expression to get parts of a URL.
But there is already a private urlUtils provider,
which relies on HTMLAnchorElement to provide this information,
and is suitable for most cases.
In order to make urlUtils more accessible in the absence of DI,
its methods were converted to standalone functions available globally.
The urlUtils.resolve method was renamed urlResolve,
and was refactored to only take 1 argument, url,
and not the 2nd "parse" boolean.
The method now always returns a parsed url.
All places in code which previously wanted a string instead of a parsed
url can now get the value from the href property of the returned object.
Tests were also added to ensure IPv6 addresses were handled correctly.
Closes #3533
Closes #2950
Closes #3249
|
|
Objects received from outside AngularJS may have had their `hasOwnProperty`
method overridden with something else. In cases where we can do this without
incurring a performance penalty we call directly on Object.prototype.hasOwnProperty
to ensure that we use the correct method.
Also, we have some internal hash objects, where the keys for the map are provided
from outside AngularJS. In such cases we either prevent `hasOwnProperty` from
being used as a key or provide some other way of preventing our objects from
having their `hasOwnProperty` overridden.
BREAKING CHANGE: Inputs with name equal to "hasOwnProperty" are not allowed inside
form or ngForm directives.
Before, inputs whose name was "hasOwnProperty" were quietly ignored and not added
to the scope. Now a badname exception is thrown.
Using "hasOwnProperty" for an input name would be very unusual and bad practice.
Either do not include such an input in a `form` or `ngForm` directive or change
the name of the input.
Closes #3331
|
|
previously the compile/link fns executed in this order controlled via priority:
- CompilePriorityHigh, CompilePriorityMedium, CompilePriorityLow
- PreLinkPriorityHigh, PreLinkPriorityMedium, PreLinkPriorityLow
- link children
- PostLinkPriorityHigh, PostLinkPriorityMedium, PostLinkPriorityLow
This was changed to:
- CompilePriorityHigh, CompilePriorityMedium, CompilePriorityLow
- PreLinkPriorityHigh, PreLinkPriorityMedium, PreLinkPriorityLow
- link children
- PostLinkPriorityLow, PostLinkPriorityMedium , PostLinkPriorityHigh
Using this order the child transclusion directive that gets replaced
onto the current element get executed correctly (see issue #3558),
and more generally, the order of execution of post linking function
makes more sense. The incorrect order was an oversight that has
gone unnoticed for many suns and moons.
(FYI: postLink functions are the default linking functions)
BREAKING CHANGE: the order of postLink fn is now mirror opposite of
the order in which corresponding preLinking and compile functions
execute.
Very few directives in practice rely on order of postLinking function
(unlike on the order of compile functions), so in the rare case
of this change affecting an existing directive, it might be necessary
to convert it to a preLinking function or give it negative priority
(look at the diff of this commit to see how an internal attribute
interpolation directive was adjusted).
Closes #3558
|
|
Previously we would stop the compilation for both regular and element
transclusion directives which was wrong. Only element transclusion directives
should be terminal.
|
|
Closes #4187
|
|
The current comment of Attributes.$observe doesn't state correctly the behavior when the attribute contains no interpolation. Specifically, it states that the observer function will never be invoked if the attribute contains no interpolation. However, the actual behavior in this case is that the observer will be invoked once during the next digest loop.
|
|
|
|
Allow `tel:` links so that click-to-call works in mobile browsers
|
|
Fix wrong behaviour that didn't allow 'data-on' and 'on' element attributes
to be interpolated by $compile. The regex now accepts any string beginning
with 'on' and with at least one more English letter.
|
|
How did compiling a templateUrl (async) directive with `replace:true` work before this commit?
1/ apply all directives with higher priority than the templateUrl directive
2/ partially apply the templateUrl directive (create `beforeTemplateNodeLinkFn`)
3/ fetch the template
4/ apply second part of the templateUrl directive on the fetched template
(`afterTemplateNodeLinkFn`)
That is, the templateUrl directive is basically split into two parts (two `nodeLinkFn` functions),
which has to be both applied.
Normally we compose linking functions (`nodeLinkFn`) using continuation - calling the linking
function of a parent element, passing the linking function of the child elements as an argument. The
parent linking function then does:
1/ execute its pre-link functions
2/ call the child elements linking function (traverse)
3/ execute its post-link functions
Now, we have two linking functions for the same DOM element level (because the templateUrl directive
has been split).
There has been multiple issues because of the order of these two linking functions (creating
controller before setting up scope locals, running linking functions before instantiating
controller, etc.). It is easy to fix one use case, but it breaks some other use case. It is hard to
decide what is the "correct" order of these two linking functions as they are essentially on the
same level.
Running them side-by-side screws up pre/post linking functions for the high priority directives
(those executed before the templateUrl directive). It runs post-linking functions before traversing:
```js
beforeTemplateNodeLinkFn(null); // do not travers
afterTemplateNodeLinkFn(afterTemplateChildLinkFn);
```
Composing them (in any order) screws up the order of post-linking functions. We could fix this by
having post-linking functions to execute in reverse order (from the lowest priority to the highest)
which might actually make a sense.
**My solution is to remove this splitting.** This commit removes the `beforeTemplateNodeLinkFn`. The
first run (before we have the template) only schedules fetching the template. The rest (creating
scope locals, instantiating a controller, linking functions, etc) is done when processing the
directive again (in the context of the already fetched template; this is the cloned
`derivedSyncDirective`).
We still need to pass-through the linking functions of the higher priority directives (those
executed before the templateUrl directive), that's why I added `preLinkFns` and `postLinkFns`
arguments to `applyDirectivesToNode`.
This also changes the "$compile transclude should make the result of a transclusion available to the
parent directive in post- linking phase (templateUrl)" unit test. It was testing that a parent
directive can see the content of transclusion in its pre-link function. That is IMHO wrong (as the
`ngTransclude` directive inserts the translusion in its linking function). This test was only passing because of
c173ca412878d537b18df01f39e400ea48a4b398, which changed the behavior of the compiler to traverse
before executing the parent linking function. That was wrong and also caused the #3792 issue, which
this change fixes.
Closes #3792
Closes #3923
Closes #3935
Closes #3927
|
|
|
