fix(animations): ensure consistent transition namespace ordering #19854

JoostK · 2017-10-22T13:51:25Z

PR Checklist

Please check if your PR fulfills the following requirements:

The commit message follows our guidelines: https://github.com/angular/angular/blob/master/CONTRIBUTING.md#commit
Tests for the changes have been added (for bug fixes / features)
Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] angular.io application / infrastructure changes
[ ] Other... Please describe:

What is the current behavior?

In #19006 a fix was implemented to properly delay the removal of nested animations in distinct components if they are queried in a parent's leave animation using animateChild. Upon testing the new behavior I found that the problem occurs once again for deeper nested components. The problem can be observed in this Plunker.

After an intense debugging session I discovered that this is caused by the fact that the inner animation is not considered as child animation of the parent's leave transition but as a root animation in itself. As such, the parent's leave transition does not wait for the supposed child animation to complete and causes the node to be removed immediately.

What is the new behavior?

Queried elements in a parent leave animation are now always considered as sub-animation of that parent's animation by assuring proper ordering of transition namespaces.

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

When including a component in a template, the component's host element is immediately appended as child of the parent node upon creation. Hence, hostElement.parentNode will be a valid reference. However, if the parent component is being inserted as an embedded view---through ngIf for example---then the parent's node itself will not have been insterted yet. This means that we cannot properly determine the position of the transition namespace, as any containsElement check will return false given that the partial DOM tree has not been inserted yet, even though it will be contained within an existing transition namespace once the partial tree is attached. This PR ensures that the registration of the transition namespace is queued if the element is not yet attached with the body node.

As a consequence of the incorrect ordering of transition namespaces, the leave transition on the parent using animateChild was unable to select the child transition as it had not been processed yet. In the end, this causes the child animation not be considered as nested transition within the parent player, but as a separate root player of its own.

In the test, it is required to inspect the players of the AnimationEngine and not those from getLog. The latter only returns the actual animation players, of which the parent leave animation is not part of given that it does not have animation instructions of its own.

I have tried a fix where the registration of transition namespaces is always queued, however that causes several tests regarding :enter transitions to fail, along with two computed style tests for pre- and post animation styles. I did not look into why exactly this happens but opted to go with the current solution.

JoostK · 2017-10-22T17:20:50Z

I looked into the performance implications of this change and it might be worthwhile to use document instead of getBodyNode as at least WebKit and Blink can then determine the result in O(1), removing the need for a node traversal if the element is actually attached.

JoostK · 2018-01-09T19:42:40Z

@matsko Can you look into this?

matsko · 2018-01-09T23:29:49Z

@JoostK thank you for finding and fixing this issue. I'm just waiting for the tests to pass (the AIO tests are a bit flaky, but they need to be green). Once that's good then I'll have this flagged as mergeable.

JoostK · 2018-07-20T20:21:01Z

@matsko Rebased onto master, this is still an issue as of today. I migrated the reproduction project to Angular 6 in Stackblitz.

matsko · 2018-12-13T23:46:41Z

http://test/OCL:225449631:BASE:225449857:1544744775588:cbb3c2d4

AndrewKushnir

LGTM 👍

AndrewKushnir · 2020-11-25T01:32:22Z

Presubmit + Global Presubmit.

AndrewKushnir · 2020-12-04T20:52:26Z

Just a quick comment: we are re-running global presubmit to make sure there are no breakages in Google's codebase. I will keep this thread updated. Thank you.

AndrewKushnir · 2020-12-08T23:57:27Z

Update: there is one failing tests in Google's codebase that requires further investigation. Reached out to the team that owns the test to get some help. Will keep this thread updated. Thank you.

AndrewKushnir · 2020-12-16T18:56:43Z

FYI, no updates from g3 team yet, so I'm adding "blocked" label for now.

AndrewKushnir · 2021-04-26T20:20:51Z

Just a quick note: I haven't received any additional info from an internal team yet. I will rebase this PR and try to run another global presubmit to see if things have changed.

When including a component in a template, the component's host element is immediately appended as child of the parent node upon creation. Hence, `hostElement.parentNode` will be a valid reference. However, if the parent component is being inserted as an embedded view—through `ngIf` for example—then the parent's node itself will not have been inserted yet. This means that we cannot properly determine the position of the transition namespace, as any `containsElement` check will return false given that the partial DOM tree has not been inserted yet, even though it will be contained within an existing transition namespace once the partial tree is attached. This commit fixes the issue by not just looking at the existence of a parent node, but rather a more extensive check using the driver's `containsElement` method.

AndrewKushnir · 2021-04-27T01:15:39Z

Presubmit + Global Presubmit.

AndrewKushnir · 2021-04-27T18:35:47Z

Global presubmit indicated that there is 1 failing target (a different one now), I will perform further investigation and keep this thread updated.

jessicajaniuk · 2021-04-28T21:20:52Z

@JoostK @AndrewKushnir What's the status of this PR? Looks like it was in Presubmit limbo.

AndrewKushnir · 2021-04-29T01:12:43Z

@jessicajaniuk I've restarted TGP a couple days ago and reached out to an internal team which owns failing target. Will update this PR once I get any news.

crisbeto

LGTM

AndrewKushnir · 2021-04-29T20:52:17Z

FYI, the code in Google's codebase was updated to work correctly with this change, so I'm removing the "blocked" label and marking this PR as ready for merge.

) When including a component in a template, the component's host element is immediately appended as child of the parent node upon creation. Hence, `hostElement.parentNode` will be a valid reference. However, if the parent component is being inserted as an embedded view—through `ngIf` for example—then the parent's node itself will not have been inserted yet. This means that we cannot properly determine the position of the transition namespace, as any `containsElement` check will return false given that the partial DOM tree has not been inserted yet, even though it will be contained within an existing transition namespace once the partial tree is attached. This commit fixes the issue by not just looking at the existence of a parent node, but rather a more extensive check using the driver's `containsElement` method. PR Close #19854

angular-automatic-lock-bot · 2021-05-31T16:22:16Z

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.}

googlebot added the cla: yes label Oct 22, 2017

jasonaden added the area: animations label Nov 14, 2017

matsko self-requested a review January 9, 2018 23:28

matsko approved these changes Jan 9, 2018

View reviewed changes

JoostK force-pushed the animations-animatechild-fix branch from 625884c to 4311e4d Compare July 20, 2018 20:17

JoostK force-pushed the animations-animatechild-fix branch from 4311e4d to 88b9257 Compare July 20, 2018 21:14

matsko approved these changes Dec 13, 2018

View reviewed changes

jasonaden added this to the needsTriage milestone Jan 29, 2019

JoostK force-pushed the animations-animatechild-fix branch from 88b9257 to f019f3b Compare November 24, 2020 19:48

pullapprove bot requested review from AndrewKushnir and crisbeto November 24, 2020 19:48

JoostK added action: review The PR is still awaiting reviews from at least one requested reviewer target: patch This PR is targeted for the next patch release type: bug/fix labels Nov 24, 2020

AndrewKushnir approved these changes Nov 25, 2020

View reviewed changes

AndrewKushnir added the action: presubmit The PR is in need of a google3 presubmit label Nov 25, 2020

mhevery self-assigned this Dec 1, 2020

mhevery added this to Needs review in mhevery-review-queue via automation Dec 4, 2020

pullapprove bot removed the area: animations label Dec 9, 2020

ngbot bot removed this from the needsTriage milestone Dec 9, 2020

mhevery added the area: animations label Dec 9, 2020

ngbot bot added this to the Backlog milestone Dec 9, 2020

pullapprove bot removed the area: animations label Dec 9, 2020

ngbot bot removed this from the Backlog milestone Dec 9, 2020

pullapprove bot added area: animations area: core Issues related to the framework runtime labels Dec 10, 2020

ngbot bot modified the milestone: Backlog Dec 10, 2020

AndrewKushnir added state: blocked and removed action: presubmit The PR is in need of a google3 presubmit labels Dec 16, 2020

AndrewKushnir self-assigned this Apr 26, 2021

AndrewKushnir force-pushed the animations-animatechild-fix branch from f019f3b to cbfe44f Compare April 27, 2021 01:13

crisbeto approved these changes Apr 29, 2021

View reviewed changes

mhevery-review-queue automation moved this from Needs review to Waiting for author Apr 29, 2021

AndrewKushnir added action: merge The PR is ready for merge by the caretaker and removed action: review The PR is still awaiting reviews from at least one requested reviewer state: blocked labels Apr 29, 2021

mhevery closed this in e27ac01 Apr 30, 2021

mhevery-review-queue automation moved this from Waiting for author to Done Apr 30, 2021

angular-automatic-lock-bot bot locked and limited conversation to collaborators May 31, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(animations): ensure consistent transition namespace ordering #19854

fix(animations): ensure consistent transition namespace ordering #19854

JoostK commented Oct 22, 2017 •

edited

JoostK commented Oct 22, 2017

JoostK commented Jan 9, 2018

matsko commented Jan 9, 2018

JoostK commented Jul 20, 2018 •

edited

matsko commented Dec 13, 2018

AndrewKushnir left a comment

AndrewKushnir commented Nov 25, 2020 •

edited

AndrewKushnir commented Dec 4, 2020

AndrewKushnir commented Dec 8, 2020

AndrewKushnir commented Dec 16, 2020

AndrewKushnir commented Apr 26, 2021

AndrewKushnir commented Apr 27, 2021 •

edited

AndrewKushnir commented Apr 27, 2021

jessicajaniuk commented Apr 28, 2021

AndrewKushnir commented Apr 29, 2021

crisbeto left a comment

AndrewKushnir commented Apr 29, 2021 •

edited

angular-automatic-lock-bot bot commented May 31, 2021

fix(animations): ensure consistent transition namespace ordering #19854

fix(animations): ensure consistent transition namespace ordering #19854

Conversation

JoostK commented Oct 22, 2017 • edited

PR Checklist

PR Type

What is the current behavior?

What is the new behavior?

Does this PR introduce a breaking change?

Other information

JoostK commented Oct 22, 2017

JoostK commented Jan 9, 2018

matsko commented Jan 9, 2018

JoostK commented Jul 20, 2018 • edited

matsko commented Dec 13, 2018

AndrewKushnir left a comment

Choose a reason for hiding this comment

AndrewKushnir commented Nov 25, 2020 • edited

AndrewKushnir commented Dec 4, 2020

AndrewKushnir commented Dec 8, 2020

AndrewKushnir commented Dec 16, 2020

AndrewKushnir commented Apr 26, 2021

AndrewKushnir commented Apr 27, 2021 • edited

AndrewKushnir commented Apr 27, 2021

jessicajaniuk commented Apr 28, 2021

AndrewKushnir commented Apr 29, 2021

crisbeto left a comment

Choose a reason for hiding this comment

AndrewKushnir commented Apr 29, 2021 • edited

angular-automatic-lock-bot bot commented May 31, 2021

JoostK commented Oct 22, 2017 •

edited

JoostK commented Jul 20, 2018 •

edited

AndrewKushnir commented Nov 25, 2020 •

edited

AndrewKushnir commented Apr 27, 2021 •

edited

AndrewKushnir commented Apr 29, 2021 •

edited