DOM_WINDOW_DESTROYED_TOPIC fires when JavaScript is not dead?
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
People
(Reporter: saschanaz, Unassigned)
References
Details
See bug 1835390, it seems location.assign() (or location.reload to be more consistent) fires DOM_WINDOW_DESTROYED_TOPIC even when JavaScript is still running.
|
||
Comment 1•2 years ago
•
|
||
DOM_WINDOW_DESTROYED_TOPIC means the window has been destroyed (disconnected from the docshell basically), it doesn't mean some JS outside the relevant realm couldn't still access objects from the destroyed window.
As far as I see everything is working as expected.
|
Reporter | |
Comment 2•2 years ago
•
|
||
outside the relevant realm
But is bug 1835390 accessing objects outside the relevant realm? I only see one realm working there.
|
|
||
Comment 3•2 years ago
|
||
Actually, same realm can access too. That is totally fine.
Say, js which is running inside an iframe does something like
/* run some JS .../
window.frameElement.remove();
/ run some more JS*/
That frame element removal destroys the relevant docshell, and nsGlobalWindowOuter::DetachFromDocShell should be called and that runs
https://searchfox.org/mozilla-central/rev/daedd554ae8a2c7f420ad77311134c8c298ba318/dom/base/nsGlobalWindowOuter.cpp#2686
which then notifies https://searchfox.org/mozilla-central/rev/daedd554ae8a2c7f420ad77311134c8c298ba318/dom/base/nsGlobalWindowInner.cpp#1129
|
|
||
Comment 4•2 years ago
|
||
And yes, I can imagine similar things with .reload() and such.
|
|
Reporter | |
Comment 5•2 years ago
•
|
||
Hmm, you are right, data:text/html,<!DOCTYPE html><iframe srcdoc="<script>frameElement.remove();alert('foo')</script>"> hits nsGlobalWindowInner::Alert() after notification (although it does not end up with actual alert popup).
I guess the point is that one should be careful when using DOM_WINDOW_DESTROYED_TOPIC for cleanup since something can access it after cleanup.
Thanks for the details, closing.
Description
•