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
Downgraded Components are not garbage collected #39911
Labels
area: upgrade
Issues related to AngularJS → Angular upgrade APIs
memory leak
Issue related to a memory leak
P4
A relatively minor issue that is not relevant to core functions
state: has PR
Milestone
Comments
cryve
changed the title
Downgraded Components are not destroyed
Downgraded Components are not garbage collected
Dec 1, 2020
petebacondarwin
added
the
area: upgrade
Issues related to AngularJS → Angular upgrade APIs
label
Dec 1, 2020
14 tasks
jelbourn
added
memory leak
Issue related to a memory leak
state: has PR
P4
A relatively minor issue that is not relevant to core functions
labels
Dec 2, 2020
gkalpak
added a commit
to gkalpak/angular
that referenced
this issue
Dec 3, 2020
Previously, due to the way the AngularJS and Angular clean-up processes interfere with each other when removing an AngularJS element that contains a downgraded Angular component, the data associated with the host element of the downgraded component was not removed. This data was kept in an internal AngularJS cache, which prevented the element and component instance from being garbage-collected, leading to memory leaks. This commit fixes this by ensuring the element data is explicitly removed when cleaning up a downgraded component. NOTE: This is essentially the equivalent of angular#26209 but for downgraded (instead of upgraded) components. Fixes angular#39911 Closes angular#39921
gkalpak
added a commit
to gkalpak/angular
that referenced
this issue
Dec 3, 2020
Previously, due to the way the AngularJS and Angular clean-up processes interfere with each other when removing an AngularJS element that contains a downgraded Angular component, the data associated with the host element of the downgraded component was not removed. This data was kept in an internal AngularJS cache, which prevented the element and component instance from being garbage-collected, leading to memory leaks. This commit fixes this by ensuring the element data is explicitly removed when cleaning up a downgraded component. NOTE: This is essentially the equivalent of angular#26209 but for downgraded (instead of upgraded) components. Fixes angular#39911 Closes angular#39921
gkalpak
added a commit
to gkalpak/angular
that referenced
this issue
Dec 3, 2020
Previously, due to the way the AngularJS and Angular clean-up processes interfere with each other when removing an AngularJS element that contains a downgraded Angular component, the data associated with the host element of the downgraded component was not removed. This data was kept in an internal AngularJS cache, which prevented the element and component instance from being garbage-collected, leading to memory leaks. This commit fixes this by ensuring the element data is explicitly removed when cleaning up a downgraded component. NOTE: This is essentially the equivalent of angular#26209 but for downgraded (instead of upgraded) components. Fixes angular#39911 Closes angular#39921
gkalpak
added a commit
to gkalpak/angular
that referenced
this issue
Dec 3, 2020
Previously, due to the way the AngularJS and Angular clean-up processes interfere with each other when removing an AngularJS element that contains a downgraded Angular component, the data associated with the host element of the downgraded component was not removed. This data was kept in an internal AngularJS cache, which prevented the element and component instance from being garbage-collected, leading to memory leaks. This commit fixes this by ensuring the element data is explicitly removed when cleaning up a downgraded component. NOTE: This is essentially the equivalent of angular#26209 but for downgraded (instead of upgraded) components. Fixes angular#39911 Closes angular#39921
gkalpak
added a commit
to gkalpak/angular
that referenced
this issue
Dec 3, 2020
Previously, due to the way the AngularJS and Angular clean-up processes interfere with each other when removing an AngularJS element that contains a downgraded Angular component, the data associated with the host element of the downgraded component was not removed. This data was kept in an internal AngularJS cache, which prevented the element and component instance from being garbage-collected, leading to memory leaks. This commit fixes this by ensuring the element data is explicitly removed when cleaning up a downgraded component. NOTE: This is essentially the equivalent of angular#26209 but for downgraded (instead of upgraded) components. Fixes angular#39911 Closes angular#39921
gkalpak
added a commit
to gkalpak/angular
that referenced
this issue
Dec 7, 2020
Previously, due to the way the AngularJS and Angular clean-up processes interfere with each other when removing an AngularJS element that contains a downgraded Angular component, the data associated with the host element of the downgraded component was not removed. This data was kept in an internal AngularJS cache, which prevented the element and component instance from being garbage-collected, leading to memory leaks. This commit fixes this by ensuring the element data is explicitly removed when cleaning up a downgraded component. NOTE: This is essentially the equivalent of angular#26209 but for downgraded (instead of upgraded) components. Fixes angular#39911 Closes angular#39921
mhevery
pushed a commit
that referenced
this issue
Dec 8, 2020
…39965) Previously, due to the way the AngularJS and Angular clean-up processes interfere with each other when removing an AngularJS element that contains a downgraded Angular component, the data associated with the host element of the downgraded component was not removed. This data was kept in an internal AngularJS cache, which prevented the element and component instance from being garbage-collected, leading to memory leaks. This commit fixes this by ensuring the element data is explicitly removed when cleaning up a downgraded component. NOTE: This is essentially the equivalent of #26209 but for downgraded (instead of upgraded) components. Fixes #39911 Closes #39921 PR Close #39965
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. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
area: upgrade
Issues related to AngularJS → Angular upgrade APIs
memory leak
Issue related to a memory leak
P4
A relatively minor issue that is not relevant to core functions
state: has PR
🐞 bug report
Affected Package
The issue may be caused by package @angular/upgrade
Is this a regression?
No.
Description
I have a hybrid app consisting of a main Angular CLI app that integrates legacy AngularJS templates via custom bundling and UI-Router. When I use a downgraded Angular component in an AngularJS template and toggle the rendering of this component with ng-if, let's say 5 times, then I can find 5 instances of the component in the heap snapshot.
This doesn't happen in a pure AngularJS template nor in a pure Angular template.
🔬 Minimal Reproduction
https://github.com/cryve/angular-downgrade-memory-leak
🌍 Your Environment
Angular Version:
Anything else relevant?
AngularJS code is manually bundled by this script: https://github.com/cryve/angular-downgrade-memory-leak/blob/main/ngx/build.js
The upgrade setup has been inspired by this article: https://www.angulararchitects.io/aktuelles/directly-upgrading-from-angularjs-1-x/
The text was updated successfully, but these errors were encountered: