The idea here is that maybe we could somehow remove the document from the window for a ghost window, and this will make many kinds of ghost window leaks go away. A common ghost window cause is window -> element -> networking channel -> window, where the last edge is invisible to the cycle collector. This depends on how easily we can just remove the document from the window without hitting null checks all over the place. Maybe something like navigating it to about:blank would work? I'm not too familiar with how that all works.
This also relies on our ghost window detection being accurate enough that we don't cause any web-visible behavior.
Even if this would not be safe enough for release it would be interesting to have this as a pref we could turn on in nightly/beta.
Created attachment 8929245 [details] [diff] [review] Experimental unlink button. This patch adds a new button to about:memory that unlinks all ghost windows when pushed. I'm not sure the nuking does anything. When I run this on the Twitter leak I have in bug 1409115, it does seem to succeed in destroying most of the DOM for the page, but the compartment remains. Some Promise object is keeping alive an IDB object, which is keeping alive the global. While we could iterate over all JS holders and find the ones pointing into the compartment (creating a sort of compartment nuking for C++) this seems particularly prone to causing null deref crashes. I haven't actually tried it yet, though.
One thing we could do is iterate over all of the JSHolders, calling Trace() on them to find pointers into the compartment we're trying to get rid of, then call Unlink() on any of those objects.
We could do that only for cross-domain cases.
Created attachment 8933509 [details] [diff] [review] Experimental unlink button. This patch adds an experimental button to about:memory that tries to run an unlink operation on any ghost windows. It does this by calling Unlink() on every JS holder that points into the compartment of the ghost window. On my test Twitter leak, it causes a crash. I think due to calling a memory reporter on an unlinked document, or something like that.
Attachment #8929245 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.