Skip to content

fix(portal): running change detection before nodes have been moved to outlet #16407

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jul 29, 2020

Conversation

crisbeto
Copy link
Member

Currently we run change detection as soon as we create a portal's embedded view and afterwards we transfer its DOM nodes into the portal outlet. This is problematic, because running change detection also executes any lifecycle hooks which means that directives inside the portal, which are looking at the DOM, will be invoked while the element is still at its old location.

Note: marking this as a P2, because it's a fairly small change and it's fixing something that's caused other timing-related issues for us in the past.

Fixes #16346.

@crisbeto crisbeto added P2 The issue is important to a large percentage of users, with a workaround target: patch This PR is targeted for the next patch release labels Jun 29, 2019
@googlebot googlebot added the cla: yes PR author has agreed to Google's Contributor License Agreement label Jun 29, 2019
Copy link
Member

@jelbourn jelbourn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jelbourn jelbourn added pr: lgtm action: merge The PR is ready for merge by the caretaker presubmit failures This PR has failures in Google's internal presubmit process and cannot be immediately merged labels Sep 5, 2019
@jelbourn
Copy link
Member

jelbourn commented Sep 6, 2019

This one breaks 8 targets in Google, looks like like it might be on the trickier side to debug

… outlet

Currently we run change detection as soon as we create a portal's embedded view and afterwards we transfer its DOM nodes into the portal outlet. This is problematic, because running change detection also executes any lifecycle hooks which means that directives inside the portal, which are looking at the DOM, will be invoked while the element is still at its old location.

Fixes angular#16346.
@crisbeto crisbeto force-pushed the 16346/portal-early-cd branch from 0e8c36a to 0d790d0 Compare June 2, 2020 20:08
@andrewseguin andrewseguin removed the presubmit failures This PR has failures in Google's internal presubmit process and cannot be immediately merged label Jul 28, 2020
@jelbourn jelbourn merged commit a388cc3 into angular:master Jul 29, 2020
jelbourn pushed a commit that referenced this pull request Jul 29, 2020
… outlet (#16407)

Currently we run change detection as soon as we create a portal's embedded view and afterwards we transfer its DOM nodes into the portal outlet. This is problematic, because running change detection also executes any lifecycle hooks which means that directives inside the portal, which are looking at the DOM, will be invoked while the element is still at its old location.

Fixes #16346.

(cherry picked from commit a388cc3)
crisbeto added a commit to crisbeto/material2 that referenced this pull request Aug 17, 2020
In angular#16407 we made some changes where we'd run change detection after transferring the portal content to the outlet, in order to handle a case where focus traps may be attached too early. This PR reverts back to triggering change detection before moving the content, because doing it after may leave behind nodes that were inserted through `ViewContainerRef` inside one one of the init hooks. The initial focus trap issue is resolved by delaying the attachment instead.

These changes fix another issue where we were assuming that component portals can only have one root node. This is true for most cases, except for when a sibling is inserted through `ViewContainerRef`.

Finally, these changes add a `detectChanges` call before moving the contents of a component portal for consistency between portals. Previously we were only doing in for template portals.

Fixes angular#20343.
crisbeto added a commit to crisbeto/material2 that referenced this pull request Aug 17, 2020
In angular#16407 we made some changes where we'd run change detection after transferring the portal content to the outlet, in order to handle a case where focus traps may be attached too early. This PR reverts back to triggering change detection before moving the content, because doing it after may leave behind nodes that were inserted through `ViewContainerRef` inside one one of the init hooks. The initial focus trap issue is resolved by delaying the attachment instead.

These changes fix another issue where we were assuming that component portals can only have one root node. This is true for most cases, except for when a sibling is inserted through `ViewContainerRef`.

Fixes angular#20343.
crisbeto added a commit to crisbeto/material2 that referenced this pull request Aug 17, 2020
In angular#16407 we made some changes where we'd run change detection after transferring the portal content to the outlet, in order to handle a case where focus traps may be attached too early. This PR reverts back to triggering change detection before moving the content, because doing it after may leave behind nodes that were inserted through `ViewContainerRef` inside one one of the init hooks. The initial focus trap issue is resolved by delaying the attachment instead.

These changes fix another issue where we were assuming that component portals can only have one root node. This is true for most cases, except for when a sibling is inserted through `ViewContainerRef`.

Fixes angular#20343.
@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Aug 29, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker cla: yes PR author has agreed to Google's Contributor License Agreement P2 The issue is important to a large percentage of users, with a workaround target: patch This PR is targeted for the next patch release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Focus trap breaks on the root of an ng-template in an overlay
5 participants