Previously, Angular would switch from the macrotask to a microtask
scheduler _only_ when the scheduler was the trigger for the
synchronization. This microtask scheduling is to ensure patterns such as
`Promise.resolve().then(() => updateAppStateAgain())` _during_
synchronization are caught and synchronized again within the same event
loop (guaranteeing that they aren't split across multiple browser paints).
The microtask scheduler should be used after any tick, not just from
those than run within the scheduler to always account for the promises
within synchronization. This is encountered most frequently during
bootstrap, which triggers the tick directly.
In this change we exempt `TestBed.tick` and
`ComponentFixture.detectChanges` from this behavior. Doing so would affect
the timing of stability and tests are quite sensitive to this (e.g.
`fixture.whenStable`). It is somewhat unfortunate that we have "special" test-only
behavior. However, it is important to acknowledge that this only affects
the test-only APIs as well. Any code in the application under test that
triggers `ApplicationRef.tick` directly would still use the microtask
scheduling behavior.
fixes#65444
When registering providers, the DI system assumes that `viewProviders` are registered before plain `providers`. This was reinforced by components always being first in the array of directive matches, only one component being allowed per node and the fact that only components can have `viewProviders`.
This breaks down if there are host directives with `providers` on the component, because they'll execute earlier, throwing off the order of operations.
These changes fix the issue by separating out the resolvers for `viewProviders` and plain `providers` and explicitly running the component's `viewProviders` resolver before any others. This also has the benefit of not attempting to resolve `viewProviders` for directives which are guaranteed not to have them.
Fixes#65724.
In the case that a component injector is destroyed before the animation
queue runs, the animation queue would fail to run because it was using a
destroyed injector. This commit changes the animation queue to run in the
context of the EnvironmentInjector, which is not destroyed until the app
is destroyed.
fixes: #65628
This commit implements a security fix to prevent XSS vulnerabilities where SVG animation elements (`<animate>`, `<set>`, etc.) could be used to modify the `href` or `xlink:href` attributes of other elements to `javascript:` URLs.
We track all effects that are created for debugging purposes in the `resolverToEffects` map. This ends up leaking memory for effects registered on long-living resolvers (e.g. on the root injector), because they stay in the array, even if the effect itself has been destroyed.
These changes add a callback to clean up the references.
Fixes#65265.
Although the prior commit has made more profiler events guaranteed symmetric
through the use of finally-blocks, there continue to be some situations
that could potentially result in asymmetric events, e.g. application
bootstrap doesn't guarantee symmetric events. This commit makes the profiler
lenient to these situations by unrolling the stack past the asymmetric event
data, eventually reaching the expected start event.
Profiler events are expected to be symmetric, yet in the case of errors this symmetry may break
if events aren't always kept in sync with their corresponding start event. This commit moves
various end events to be run from a finally-block, allowing them to notify the profiler even
when an error has occurred.
Fixes#62947
Although the prior commit has made more profiler events guaranteed symmetric
through the use of finally-blocks, there continue to be some situations
that could potentially result in asymmetric events, e.g. application
bootstrap doesn't guarantee symmetric events. This commit makes the profiler
lenient to these situations by unrolling the stack past the asymmetric event
data, eventually reaching the expected start event.
Profiler events are expected to be symmetric, yet in the case of errors this symmetry may break
if events aren't always kept in sync with their corresponding start event. This commit moves
various end events to be run from a finally-block, allowing them to notify the profiler even
when an error has occurred.
Fixes#62947
The `fullInheritane` flag from the metadata and the `CopyDefinitionFeature` that it controls appear to no longer be used since `fullInheritance` is always false. The feature appears to have been there to support ngcc which was removed some time ago.
We accounted for skipping leave animations during moves, but not swaps.
This accounts for the swap cases and updates how we deal with swaps and
moves. Now we always queue animations and then essentially dequeue them
if we attach them back in the same render pass.
fixes: #64818fixes: #64730
When working with a proxy object such as signal forms' `Field`,
accessing the `lenght` or `Symbol.iterator` may trgger a reactive read.
This change ensures that `@for` properly captrues this before clearing
the active consumer.
PR Close#64113
We were clearing duplicate nodes when `animate.enter` fired fast, but not when solely `animate.leave` is fired and rapid toggles occur. This ensures that the `cancelLeavingNodes` function is called in all cases instead of just enter animations.
fixes: #64581
PR Close#64592
In some rare cases, it seems the animation queue disappears despite being afterEveryRender. This updates the animation scheduler to be afterNextRender instead and only schedules it when we need to.
fixes: #64423
PR Close#64441
When adding and removing items in a `@for` loop, the `animate.leave` event binding instruction was not updated to use the same logic as the class function when the animation queue was added. We were not returning the correct signature for the `animate.leave` function, which caused the animation to not trigger correctly. This updates the event binding instruction to use the same logic as the class function when adding the animation to the queue.
fixes: #64336
PR Close#64413
Renames the control directive and the input that users set to bind a
field to a UI control.
Previously users would do:
```
<input [control]="someField">
```
Now users will do:
```
<input [filed]="someField">
```
PR Close#64300
Adds support for customizing the `IntersectionObserver` options for the `on viewport`, `prefetch on viewport` and `hydrate on viewport` triggers.
Note that the options need to be a static object literal, e.g. `@defer (on viewport(trigger, {rootMargin: '123px'})`.
Fixes#52799.
PR Close#64130
Our code ensuring host binding composition for animations was causing the early exit and removal of
elements when multiple transitions were present on the same element. This commit fixes the issue by
ensuring that we properly keep track of all the promise resolvers on the LView and then only
call them once we've properly waited for the longest animation to finish.
fixes: #64209
PR Close#64225
These tests were not properly validating against the host binding changes due to the fact that the styles were on the wrong components in some of the host binding cases.
PR Close#64225
* Emit a `ɵɵcontrol` instruction in place of `ɵɵproperty` for property
bindings named "control". This instruction cannot be chained, but is
otherwise functionally equivalent.
* Upcoming changes will use the `ɵɵcontrol` instruction to bind a signal
form field to a UI control (be it a native element or custom directive).
PR Close#63773
Content Projected nodes are not destroyed and recreated, like every other
situation. Enter and Leave animations were ephemeral and are
expected to run once, and then be cleared. This means that for content projection
cases, the animations would only ever work the first time they were shown / hid.
In order to resolve this, we move to an animation queue that re-runs the animation
functions stored in the LView. In most cases, this animation will run once on creation.
For content projection, the enter and leave animations will fire more than once. Animations
are stored on the LView, but indexed and scheduled by whichever RNode needs to be animated.
So we only run animations for an affected RNode, rather than potentially all in the LView.
This also moves the queue to afterRender, which is safer than right after template
execution in refreshView.
fixes: #63418fixes: #64065fixes: #63901
PR Close#63776
Content Projected nodes are not destroyed and recreated, like every other
situation. Enter and Leave animations were ephemeral and are
expected to run once, and then be cleared. This means that for content projection
cases, the animations would only ever work the first time they were shown / hid.
In order to resolve this, we move to an animation queue that re-runs the animation
functions stored in the LView. In most cases, this animation will run once on creation.
For content projection, the enter and leave animations will fire more than once. Animations
are stored on the LView, but indexed and scheduled by whichever RNode needs to be animated.
So we only run animations for an affected RNode, rather than potentially all in the LView.
This also moves the queue to afterRender, which is safer than right after template
execution in refreshView.
fixes: #63418fixes: #64065fixes: #63901
PR Close#63776
The event listeners for animationstart and animationend weren't properly checking whether the animation event fired matched the node we're bound to, since animation events bubble. This resulted in child node animation events bubbling up and causing elements to get prematurely removed.
fixes: #64084
PR Close#64088
This adds an optional flag to the renderer on `removeChild` called `requireSynchronousElementRemoval`, which can tell any downstream renderer that elements need to be removed synchronously. This gets passed down to the legacy animation renderer to ensure that any elements that set this flag aren't impacted by that renderers changes to timing.
fixes: #63893
PR Close#63921
https://github.com/angular/angular/pull/62630 made it so that all ARIA
property bindings would write to their corresponding attribute instead.
The primary motivation for this change was to ensure that ARIA
attributes were always rendered correctly on the server, where the
emulated DOM may not correctly reflect ARIA properties as attributes.
Furthermore, this change added support for binding to ARIA attributes
using the property binding syntax (e.g. `[aria-label]`).
Unfortunately, https://github.com/angular/angular/pull/62630 relied on
the incorrect assumptions that an ARIA property name could be converted
to its attribute name (without hardcoding the conversion), and that the
value of an ARIA property matched its corresponding attribute. For
example, the `ariaLabelledByElements` property's value is an array of
DOM elements, while the corresponding `aria-labelledby` attribute's
value is a string containing the IDs of the DOM elements.
This partially reverts https://github.com/angular/angular/pull/62630 so
that only property bindings with ARIA attribute names (begin with
`aria-`) are converted to attribute bindings.
* `[ariaLabel]` will revert to binding to the `ariaLabel` property.
* `[aria-label]` will continue binding to the `aria-label` attribute.
Note the only difference between `[aria-label]` and `[attr.aria-label]`
is that the former will attempt to bind to inputs of the same name while
the latter will not.
PR Close#63925
This option was deprecated by #55778.
BREAKING CHANGE: The `interpolation` option on Components has been removed. Only the default `{{ ... }}` is now supported.
PR Close#63474
The diagnostic will raise an error when required initializers (input, model, queries) are invoked the context of property initializers and contructors.
Docs will be provided in a follow-up
fixes#63602
PR Close#63614