Issue:
async pipe could trigger digest after scope was destroyed.
It could result in memory leak, because digest will trigger async pipe (like a filter), making it to subscribe observable in already destroyed scope (and $destroy won't happen again).
The source of the problem for async pipe is _markForCheck method, that sets timeout, and triggers $digest without checking if scope is destroyed.
Solution: track timeouts and clean them while _dispose and before setting new timeout.
For test, set of async-destroy components were created. Clicking 'start' button dispatches change in Subject imitating application state. If 'Memory leak' (when digest called after scope being destroyed) happened, alert message will be shown. To test fail scenario comment clearTimeout lines if async pipe.
The key point is "middle" async-destroy-container component that on $destroy triggers synchronous change of Subject. Thats a scenario when component on destroy want to change the state of application.
Issue: async pipe could trigger digest after scope was destroyed. It could result in memory leak, because digest will trigger async pipe (like a filter), making it to subscribe observable in already destroyed scope (and
$destroywon't happen again). The source of the problem for async pipe is_markForCheckmethod, that sets timeout, and triggers$digestwithout checking if scope is destroyed. Solution: track timeouts and clean them while_disposeand before setting new timeout.For test, set of
async-destroycomponents were created. Clicking 'start' button dispatches change inSubjectimitating application state. If 'Memory leak' (when digest called after scope being destroyed) happened, alert message will be shown. To test fail scenario commentclearTimeoutlines ifasyncpipe. The key point is "middle"async-destroy-containercomponent that on$destroytriggers synchronous change ofSubject. Thats a scenario when component on destroy want to change the state of application.