@defer: placeholder and loading blocks are not removed by BaseAnimationRenderer (TransitionAnimationEngine) #51970

elgreco247 · 2023-10-01T11:59:30Z

Which @angular/* package(s) are the source of the bug?

animations

Is this a regression?

No

Description

The defer control flow blocks @placeholder and @loading are not removed when the animation providers are loaded (via provideAnimations()).

The problem seems to be in the TransitionAnimationEngine, which is called by the BaseAnimationRenderer when a node removal is requested:

angular/packages/animations/browser/src/render/transition_animation_engine.ts

Line 748 in c4d77fd

const hostNS = this.namespacesByHostElement.get(element);

The host element namespace is undefined and thus the node is not removed.

Please provide a link to a minimal reproduction of the bug

https://stackblitz.com/edit/stackblitz-starters-s7jtnu?file=src%2Fapp%2Fapp.component.ts

Please provide the exception or error you saw

see above

Please provide the environment you discovered this bug in (run `ng version`)

Angular CLI: 17.0.0-next.6
Node: 18.18.0
Package Manager: npm 9.4.2
OS: linux x64

Angular: 17.0.0-next.6
... animations, cli, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1700.0-next.6
@angular-devkit/build-angular   17.0.0-next.6
@angular-devkit/core            17.0.0-next.6
@angular-devkit/schematics      17.0.0-next.6
@schematics/angular             17.0.0-next.6
rxjs                            7.8.1
typescript                      5.2.2
zone.js                         0.14.0

Anything else?

No response

The text was updated successfully, but these errors were encountered:

crisbeto · 2023-10-01T19:43:44Z

I looked into it a bit. It's actually a change detection issue, not an animations issue. E.g. if you add a <button (click)> in the component, it'll remove the old nodes when the button is clicked.

The one fix I have for it so far is to add detectChangesInternal(embeddedLView[TVIEW], embeddedLView, null); at the bottom of renderDeferBlockState, although I feel that might be a bit heavy-handed.

…ations are enabled Fixes an issue where if animations are enabled, deferred blocks don't remove their placeholder blocks immediately from the DOM. The problem is that we register the event handlers in `afterRender` which runs outside the zone, but the logic that removes the DOM nodes during animations is tied to change detection. These changes resolve the issue by binding the listeners inside the zone. This was the intetion from the beggining, I just forgot that `afterRender` runs outside the zone. Fixes angular#51970.

…ations are enabled Fixes an issue where if animations are enabled, deferred blocks don't remove their placeholder blocks immediately from the DOM. The problem is that we register the event handlers in `afterRender` which runs outside the zone, but the logic that removes the DOM nodes during animations is tied to change detection. These changes resolve the issue by binding the listeners inside the zone. This was the intention from the beginning, I just forgot that `afterRender` runs outside the zone. Fixes angular#51970.

angular-automatic-lock-bot · 2023-11-02T00:08:37Z

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}

…ations are enabled (angular#51971) Fixes an issue where if animations are enabled, deferred blocks don't remove their placeholder blocks immediately from the DOM. The problem is that we register the event handlers in `afterRender` which runs outside the zone, but the logic that removes the DOM nodes during animations is tied to change detection. These changes resolve the issue by binding the listeners inside the zone. This was the intention from the beginning, I just forgot that `afterRender` runs outside the zone. Fixes angular#51970. PR Close angular#51971

…zone When Angular receives a clear indication that change detection should run again, this should not be ignored, regardless of what Zone it happened in. This change updates the default change detection scheduling approach of Zone-based applications to ensure a change detection will run when these events happen outside the Angular zone (which includes, for example, updating a signal that's read in a template, setting an input of a `ComponentRef`, attaching a view marked for check, calling `ChangeDetectorRef.markForCheck`, etc.). This does not apply to applications using `NoopNgZone` or those which have a custom `NgZone` implementation without ZoneJS. The impact of this change will most often be seen in existing unit tests. Tests execute outside the Angular Zone and this can mean that state in the test is not fully recognized by Angular. Now that Angular will ensure change detection _does_ run, even when the state update originates from outside the zone, tests may observe additional rounds of change detection compared to the previous behavior. Often, this should be seen as more correct and the test should be updated, but in cases where it is too much effort to debug, the test can revert to the old behavior by adding `provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})` to the `TestBed` providers. fixes angular#53844 fixes angular#53841 fixes angular#52610 fixes angular#53566 fixes angular#52940 fixes angular#51970 fixes angular#51768 fixes angular#50702 fixes angular#50259 fixes angular#50266 fixes angular#50160 fixes angular#49940 fixes angular#49398 fixes angular#48890 fixes angular#48608 fixes angular#45105 fixes angular#42241 fixes angular#41553 fixes angular#37223 fixes angular#37062 fixes angular#35579 fixes angular#31695 fixes angular#24728 fixes angular#23697 fixes angular#19814 fixes angular#13957 fixes angular#11565 fixes angular#15770 fixes angular#15946 fixes angular#18254 fixes angular#19731 fixes angular#20112 fixes angular#22472 fixes angular#23697 fixes angular#24727 fixes angular#47236 BREAKING CHANGE: Angular will ensure change detection runs, even when the state update originates from outside the zone, tests may observe additional rounds of change detection compared to the previous behavior. This change will be more likely to impact existing unit tests. This should usually be seen as more correct and the test should be updated, but in cases where it is too much effort to debug, the test can revert to the old behavior by adding `provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})` to the `TestBed` providers. Similarly, applications which may want to update state outside the zone and _not_ trigger change detection can add `provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})` to the providers in `bootstrapApplication` or add `schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the `BootstrapOptions` of `bootstrapModule`.

…zone When Angular receives a clear indication that change detection should run again, this should not be ignored, regardless of what Zone it happened in. This change updates the default change detection scheduling approach of Zone-based applications to ensure a change detection will run when these events happen outside the Angular zone (which includes, for example, updating a signal that's read in a template, setting an input of a `ComponentRef`, attaching a view marked for check, calling `ChangeDetectorRef.markForCheck`, etc.). This does not apply to applications using `NoopNgZone` or those which have a custom `NgZone` implementation without ZoneJS. The impact of this change will most often be seen in existing unit tests. Tests execute outside the Angular Zone and this can mean that state in the test is not fully recognized by Angular. Now that Angular will ensure change detection _does_ run, even when the state update originates from outside the zone, tests may observe additional rounds of change detection compared to the previous behavior. Often, this should be seen as more correct and the test should be updated, but in cases where it is too much effort to debug, the test can revert to the old behavior by adding `provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})` to the `TestBed` providers. fixes angular#55238 fixes angular#53844 fixes angular#53841 fixes angular#52610 fixes angular#53566 fixes angular#52940 fixes angular#51970 fixes angular#51768 fixes angular#50702 fixes angular#50259 fixes angular#50266 fixes angular#50160 fixes angular#49940 fixes angular#49398 fixes angular#48890 fixes angular#48608 fixes angular#45105 fixes angular#42241 fixes angular#41553 fixes angular#37223 fixes angular#37062 fixes angular#35579 fixes angular#31695 fixes angular#24728 fixes angular#23697 fixes angular#19814 fixes angular#13957 fixes angular#11565 fixes angular#15770 fixes angular#15946 fixes angular#18254 fixes angular#19731 fixes angular#20112 fixes angular#22472 fixes angular#23697 fixes angular#24727 fixes angular#47236 BREAKING CHANGE: Angular will ensure change detection runs, even when the state update originates from outside the zone, tests may observe additional rounds of change detection compared to the previous behavior. This change will be more likely to impact existing unit tests. This should usually be seen as more correct and the test should be updated, but in cases where it is too much effort to debug, the test can revert to the old behavior by adding `provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})` to the `TestBed` providers. Similarly, applications which may want to update state outside the zone and _not_ trigger change detection can add `provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})` to the providers in `bootstrapApplication` or add `schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the `BootstrapOptions` of `bootstrapModule`.

…zone (#55102) When Angular receives a clear indication that change detection should run again, this should not be ignored, regardless of what Zone it happened in. This change updates the default change detection scheduling approach of Zone-based applications to ensure a change detection will run when these events happen outside the Angular zone (which includes, for example, updating a signal that's read in a template, setting an input of a `ComponentRef`, attaching a view marked for check, calling `ChangeDetectorRef.markForCheck`, etc.). This does not apply to applications using `NoopNgZone` or those which have a custom `NgZone` implementation without ZoneJS. The impact of this change will most often be seen in existing unit tests. Tests execute outside the Angular Zone and this can mean that state in the test is not fully recognized by Angular. Now that Angular will ensure change detection _does_ run, even when the state update originates from outside the zone, tests may observe additional rounds of change detection compared to the previous behavior. Often, this should be seen as more correct and the test should be updated, but in cases where it is too much effort to debug, the test can revert to the old behavior by adding `provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})` to the `TestBed` providers. fixes #55238 fixes #53844 fixes #53841 fixes #52610 fixes #53566 fixes #52940 fixes #51970 fixes #51768 fixes #50702 fixes #50259 fixes #50266 fixes #50160 fixes #49940 fixes #49398 fixes #48890 fixes #48608 fixes #45105 fixes #42241 fixes #41553 fixes #37223 fixes #37062 fixes #35579 fixes #31695 fixes #24728 fixes #23697 fixes #19814 fixes #13957 fixes #11565 fixes #15770 fixes #15946 fixes #18254 fixes #19731 fixes #20112 fixes #22472 fixes #23697 fixes #24727 fixes #47236 BREAKING CHANGE: Angular will ensure change detection runs, even when the state update originates from outside the zone, tests may observe additional rounds of change detection compared to the previous behavior. This change will be more likely to impact existing unit tests. This should usually be seen as more correct and the test should be updated, but in cases where it is too much effort to debug, the test can revert to the old behavior by adding `provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})` to the `TestBed` providers. Similarly, applications which may want to update state outside the zone and _not_ trigger change detection can add `provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})` to the providers in `bootstrapApplication` or add `schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the `BootstrapOptions` of `bootstrapModule`. PR Close #55102

…zone (angular#55102) When Angular receives a clear indication that change detection should run again, this should not be ignored, regardless of what Zone it happened in. This change updates the default change detection scheduling approach of Zone-based applications to ensure a change detection will run when these events happen outside the Angular zone (which includes, for example, updating a signal that's read in a template, setting an input of a `ComponentRef`, attaching a view marked for check, calling `ChangeDetectorRef.markForCheck`, etc.). This does not apply to applications using `NoopNgZone` or those which have a custom `NgZone` implementation without ZoneJS. The impact of this change will most often be seen in existing unit tests. Tests execute outside the Angular Zone and this can mean that state in the test is not fully recognized by Angular. Now that Angular will ensure change detection _does_ run, even when the state update originates from outside the zone, tests may observe additional rounds of change detection compared to the previous behavior. Often, this should be seen as more correct and the test should be updated, but in cases where it is too much effort to debug, the test can revert to the old behavior by adding `provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})` to the `TestBed` providers. fixes angular#55238 fixes angular#53844 fixes angular#53841 fixes angular#52610 fixes angular#53566 fixes angular#52940 fixes angular#51970 fixes angular#51768 fixes angular#50702 fixes angular#50259 fixes angular#50266 fixes angular#50160 fixes angular#49940 fixes angular#49398 fixes angular#48890 fixes angular#48608 fixes angular#45105 fixes angular#42241 fixes angular#41553 fixes angular#37223 fixes angular#37062 fixes angular#35579 fixes angular#31695 fixes angular#24728 fixes angular#23697 fixes angular#19814 fixes angular#13957 fixes angular#11565 fixes angular#15770 fixes angular#15946 fixes angular#18254 fixes angular#19731 fixes angular#20112 fixes angular#22472 fixes angular#23697 fixes angular#24727 fixes angular#47236 BREAKING CHANGE: Angular will ensure change detection runs, even when the state update originates from outside the zone, tests may observe additional rounds of change detection compared to the previous behavior. This change will be more likely to impact existing unit tests. This should usually be seen as more correct and the test should be updated, but in cases where it is too much effort to debug, the test can revert to the old behavior by adding `provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})` to the `TestBed` providers. Similarly, applications which may want to update state outside the zone and _not_ trigger change detection can add `provideZoneChangeDetection({schedulingMode: NgZoneSchedulingMode.NgZoneOnly})` to the providers in `bootstrapApplication` or add `schedulingMode: NgZoneSchedulingMode.NgZoneOnly` to the `BootstrapOptions` of `bootstrapModule`. PR Close angular#55102

crisbeto self-assigned this Oct 1, 2023

crisbeto added area: core Issues related to the framework runtime state: has PR core: defer Issues related to @defer blocks. labels Oct 1, 2023

ngbot bot modified the milestone: needsTriage Oct 1, 2023

crisbeto mentioned this issue Oct 1, 2023

fix(core): deferred blocks not removing content immediately when animations are enabled #51971

Closed

alxhub closed this as completed in 4f69d62 Oct 2, 2023

angular-automatic-lock-bot bot locked and limited conversation to collaborators Nov 2, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

@defer: placeholder and loading blocks are not removed by BaseAnimationRenderer (TransitionAnimationEngine) #51970

@defer: placeholder and loading blocks are not removed by BaseAnimationRenderer (TransitionAnimationEngine) #51970

elgreco247 commented Oct 1, 2023 •

edited

crisbeto commented Oct 1, 2023 •

edited

angular-automatic-lock-bot bot commented Nov 2, 2023

@defer: placeholder and loading blocks are not removed by BaseAnimationRenderer (TransitionAnimationEngine) #51970

@defer: placeholder and loading blocks are not removed by BaseAnimationRenderer (TransitionAnimationEngine) #51970

Comments

elgreco247 commented Oct 1, 2023 • edited

Which @angular/* package(s) are the source of the bug?

Is this a regression?

Description

Please provide a link to a minimal reproduction of the bug

Please provide the exception or error you saw

Please provide the environment you discovered this bug in (run ng version)

Anything else?

crisbeto commented Oct 1, 2023 • edited

angular-automatic-lock-bot bot commented Nov 2, 2023

elgreco247 commented Oct 1, 2023 •

edited

Please provide the environment you discovered this bug in (run `ng version`)

crisbeto commented Oct 1, 2023 •

edited