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.