| Age | Commit message (Collapse) | Author |
|---|
|
Closes #3759
|
|
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
|
|
Closes #1705
|
|
jqLite previously used `elt.className` to add and remove classes from a DOM Node, but
because the className property is not writable on SVG elements, it doesn't work with
them. This patch replaces accesses to `className` with `get/setAttribute`.
`classList` was also considered as a solution, but because only IE10+ supports it, we
have to wait. :'(
The JqLiteAddClass/JQLiteRemoveClass methods are now also used directly by $animate
to work around the jQuery not being able to handle class modifications on SVG elements.
Closes #3858
|
|
The problem was in keeping the values of `attrNameStart` and `attrNameEnd` between directive loop iterations which lead to the compiler looking for multi-element ranges for any directives that happened to be in the directive list after one that was applied on a range. For instance, having a ng-repeat-start and ng-class on a single element with ng-repeat being resolved first made the compiler look for an ng-repeat-end for both ng-repeat and ng-class because the `attrNameEnd` was not reset to a falsy value before the second iteration. As the result, an exception saying the block end element could not be found and the second directive was not actually applied.
Closes #4002
|
|
initially undefined
Previously if the collection model was set to undefined on the first digest,
the repeater would get confused and not use the correct tracking function
for associating model with dom elements in the repeater.
Closes #4145
Closes #3964
|
|
Ref: https://github.com/angular/angular.dart/blob/master/test/directives/ng_non_bindable_spec.dart
|
|
Ref: https://github.com/angular/angular.js/pull/4045
I have this sinking feeling that support this use case sort of
encourages binding to function that blindly trust some html. For now,
I'm fixing the issue while I think about the use cases some more.
In the case of a function that performs any non-trivial work before
wrapping the value (e.g. the showdown filter in issue #3980, or the
binding to a simply wrapper function in issue #3932 if it did anything
meaty), this fix makes it "work" - but performance is going to suck -
you should bind to some other thing on scope that watches the actual
source and adjusts itself when that changes (e.g. the showdown filter.)
For the case of the wrapper in #3932, if one isn't performing
sanitization or some such thing - then you the developer has insight
into why that value is safe in that particular context - and it should
be available simply by name and not as a result of a function taking any
arbitrary input to make auditing of security a little saner.
Closes #3932, #3980
|
|
BREAKING CHANGE: ngInclude's priority is now set to 1000
It's quite rare for anyone to depend on explicity directive priority,
but if a custom directive that needs to run before ngInclude exists,
it should have its priority checked and adjusted if needed.
Closes #3793
|
|
|
|
|
|
|
|
and move animations
Closes #3727
Closes #3603
|
|
cycle is complete
|
|
|
|
Closes #3809
|
|
It's great that IE11 wants to be compatible enough that it doesn't want
to be special cased and treated differently.
However, as long as one has to have a different code path for IE than
for the other supported browsers, we still need to detect and special
case it. For instance, our URL parsing code still needs the same
workaround the we used for IE10. We still see the same Access denied /
TypeError exceptions when setting certain values. FYI, Angular doesn't
generally blindly test for IE – we also check the version number.
Thanks to modern.ie for the free IE11 test VM.
Closes #3682
|
|
Making assertions on state (rather than interactions) is better anyway.
|
|
This reverts commit cbf06a5d64aba537f0e2679a194d3998d8365493.
This turned out to be a bad idea because it allow us to fast-forward
the wall clock time (see previous commit).
|
|
This change causes a new $digest to be scheduled in the next tick if
a task was was sent to the $evalAsync queue from outside of a $digest
or an $apply.
While this mode of operation is not common for most of the user code,
this change means that $q promises that utilze $evalAsync queue to
guarantee asynchronicity of promise apis will now also resolve outside
of a $digest, which turned out to be a big pain point for some developers.
The implementation ensures that we don't do more work than needed and
that we coalese as much work as possible into a single $digest.
The use of $browser instead of setTimeout ensures that we can mock out
and control the scheduling of "auto-flush", which should in theory
allow all of the existing code and tests to work without negative
side-effects.
Closes #3539
Closes #2438
|
|
When calling $timeout.flush with or without a delay an exception should
be thrown if there is nothing to be flushed.
This prevents tests from flushing stuff unnecessarily.
BREAKING CHANGE: calling $timeout.flush(delay) when there is no task to be flushed
within the delay throws an exception now.
Please adjust the delay or remove the flush call from your tests as the exception
is a signed of a programming error.
|
|
|
|
|
|
History API not working properly on Boxee box browser (old Webkit)
problem similar to the one on Android < 4
|
|
This reverts commit 637c9b1611c5a75a42048ee1c591521c7031751a.
(ref #3633 and #3646)
The minimum bar for $sce is IE8 in standards mode. IE7 standards mode
is not supported. If you must support IE7, you should disable $sce
completely.
angular.module('ie7support', []).config(function($sceProvider) {
// Completely disable SCE to support IE7.
$sceProvider.enabled(false);
});
|
|
Uses the changes from @jamestalmage's fix in #3535. (thanks!)
Closes #3535
|
|
Changes documentMode test version to 7 in order to support IE 8 in IE 7 standards
mode while still protecting against quirks mode.
documentMode returns the following values:
5 - quirks mode,
7 - IE 7 standards mode,
8 - IE 8 standards mode.
Closes #3633
Closes #3646
|
|
when the transluded content is being teleported to the translusion point, we should ensure that
the translusion point is empty before appending otherwise we end up with junk before the transcluded
content
|
|
previously the translusion was appended the the ngTranslude element via
$evalAsync which makes the transluded dom unavailable to parent
post-linking functions. By appending translusion in linking phase,
post-linking functions will be able to access it.
|
|
|
|
|
|
Code was evaluating !expression[key] while attempting to
see if the key was present, but this was evaluating to true for
false values as well as missing keys.
Closes #2797.
|
|
When a parsed function call returns a promise, the evaluated value
is the resolved value of the promise rather than the promise object.
Closes #3503
|
|
Closes #3566
|
|
Make sure $timeout callbacks are forgotten about immediately after
execution or cancellation.
Previously when passing invokeApply=false, the cleanup used $q and so
would be pending until the next $digest was triggered. This does not
make a large functional difference, but can be very visible when
looking at memory consumption of an app or debugging around the
$$asyncQueue - these callbacks can have a big retaining tree.
|
|
sorry, my bad!
|
|
|
|
|
|
we can never get to this state, so dropping the error
|
|
After a recent refactoring using $location in the default hashbang mode would result
in hash url being initialized unnecessarily in cases when the base url didn't end
with a slash.
for example http://localhost:8000/temp.html would get rewritten as
http://location:8000/temp.html#/temp.html by error.
|
|
This fixes regression introduced by #3514 (5c560117) - this commit is being
reverted here and a better fix is included.
The regression caused the controller to be instantiated before the isolate scope
was initialized.
Closes #3493
Closes #3482
Closes #3537
Closes #3540
|
|
transclusion system
|
|
BREAKING CHANGE: the `always` method has been renamed to `finally`.
The reason for this change is to align `$q` with the Q promises library,
despite the fact that this makes it a bit more difficult to
use with non-ES5 browsers, like IE8.
`finally` also goes well together with `catch` api that was added to
$q recently and is part of the DOM promises standard.
To migrate the code follow the example below:
Before:
$http.get('/foo').always(doSomething);
After:
$http.get('/foo').finally(doSomething);
or for IE8 compatible code:
$http.get('/foo')['finally'](doSomething);
|
|
Now we can instead this
promise.then(null, errorHandler)
with this
promise.catch(errorhandler)
Closes #2048
Closes #3476
|
|
Controllers should be always instantiated after compile fn runs, but before
pre-link fn runs. This way, controllers are available to pre-link fns that
request them.
Previously this was broken for async directives (directives with templateUrl).
Closes #3493
Closes #3482
Closes #3514
|
|
Closes #3459
|
|
Closes #3459
|
|
|
|
|
|
Errors I've documented so far:
- `$injector:cdep`
- `$injector:itkn`
- `$injector:modulerr`
- `$injector:nomod`
- `$injector:pget`
- `$injector:unpr`
- `ng:areq`
- `ng:cpi`
- `ng:cpws`
- `ngModel:noass`
Closes #3430
|
