Open
Bug 1388834
Opened 7 years ago
Updated 2 years ago
Consider breaking down the document of ghost windows
Categories
(Core :: DOM: Core & HTML, enhancement, P2)
Core
DOM: Core & HTML
Tracking
()
NEW
People
(Reporter: mccr8, Unassigned)
References
(Blocks 2 open bugs)
Details
Attachments
(1 file, 1 obsolete file)
22.79 KB,
patch
|
Details | Diff | Splinter Review |
No description provided.
Updated•7 years ago
|
Priority: -- → P2
Reporter | ||
Comment 1•7 years ago
|
||
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.
Reporter | ||
Comment 2•7 years ago
|
||
This also relies on our ghost window detection being accurate enough that we don't cause any web-visible behavior.
Comment 3•7 years ago
|
||
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.
Reporter | ||
Comment 4•7 years ago
|
||
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.
Reporter | ||
Comment 5•7 years ago
|
||
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.
Comment 6•7 years ago
|
||
We could do that only for cross-domain cases.
Reporter | ||
Comment 7•7 years ago
|
||
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.
Reporter | ||
Updated•7 years ago
|
Attachment #8929245 -
Attachment is obsolete: true
Assignee | ||
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•