-
Notifications
You must be signed in to change notification settings - Fork 26.2k
fix(upgrade): correctly destroy nested downgraded component #22400
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
Conversation
You can preview 78fe92e at https://pr22400-78fe92e.ngbuilds.io/. |
adapter.registerCleanup(); | ||
expect(registry.getAllTestabilities().length).toEqual(1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is the reason for moving this line?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No reason 😁
I was trying something out and forgot to revert than part. I'll revert it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM when Travis and CircleCI are happy.
78fe92e
to
048a4f5
Compare
You can preview 048a4f5 at https://pr22400-048a4f5.ngbuilds.io/. |
048a4f5
to
67c5427
Compare
You can preview 67c5427 at https://pr22400-67c5427.ngbuilds.io/. |
Previously, when a downgraded component was destroyed in a way that did not trigger the `$destroy` event on the element (e.g. when a parent element was removed from the DOM by Angular, not AngularJS), the `ComponentRef` was not destroyed and unregistered. This commit fixes it by listening for the `$destroy` event on both the element and the scope. Fixes angular#22392
67c5427
to
2183d02
Compare
You can preview 2183d02 at https://pr22400-2183d02.ngbuilds.io/. |
Can the caretaker run a presubmit for this one please? |
Previously, when a downgraded component was destroyed in a way that did not trigger the `$destroy` event on the element (e.g. when a parent element was removed from the DOM by Angular, not AngularJS), the `ComponentRef` was not destroyed and unregistered. This commit fixes it by listening for the `$destroy` event on both the element and the scope. Fixes #22392 PR Close #22400
…22400) Previously, when a downgraded component was destroyed in a way that did not trigger the `$destroy` event on the element (e.g. when a parent element was removed from the DOM by Angular, not AngularJS), the `ComponentRef` was not destroyed and unregistered. This commit fixes it by listening for the `$destroy` event on both the element and the scope. Fixes angular#22392 PR Close angular#22400
…22400) Previously, when a downgraded component was destroyed in a way that did not trigger the `$destroy` event on the element (e.g. when a parent element was removed from the DOM by Angular, not AngularJS), the `ComponentRef` was not destroyed and unregistered. This commit fixes it by listening for the `$destroy` event on both the element and the scope. Fixes angular#22392 PR Close angular#22400
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
PR Checklist
Docs have been added / updated (for bug fixes / features)PR Type
What is the current behavior?
When a downgraded component is destroyed in a way that does not trigger the
$destroy
event on the element (e.g. when a parent element was removed from the DOM by Angular, not AngularJS), theComponentRef
is not destroyed and unregistered.Issue Number: #22392
What is the new behavior?
Downgraded components are always correctly destroyed and unregistered.
Does this PR introduce a breaking change?
Other information
Fixes #22392.