Fix GetInProcessParentDocshell usage in nsDocShell::HasUnloadedParent
Categories
(Core :: DOM: Navigation, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox81 | --- | fixed |
People
(Reporter: kmag, Assigned: smacleod)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
Updated•3 years ago
|
Updated•3 years ago
|
Comment 1•3 years ago
|
||
Should be possible to recursively check if our parent WindowContext
is the current on in it's BrowsingContext
up the tree, only checking the docshell if it's present.
Updated•3 years ago
|
Assignee | ||
Comment 2•3 years ago
•
|
||
(In reply to Nika Layzell [:nika] (ni? for response) from comment #1)
... only checking the docshell if it's present.
If I understand correctly, this means we'd only be checking same origin docshells up the tree. So if we had the situation a.com <- b.com <- a.com
, e.g.:
<!-- http://a.com -->
<iframe src="b.com"></iframe>
<!-- http://b.com -->
<iframe src="http://a.com/frame.html"></iframe>
If nsDocShell::HasUnloadedParent
is called on the http://a.com/frame.html
docshell, we'd end up not checking if the docshell for b.com
is unloaded. Is this okay because if it was unloaded http://a.com/frame.html
's parent WindowContext
(http://b.com
) wouldn't be the current WindowContext
of the BrowsingContext
, so that's how we're checking it? or is there some other reason we can skip the check for OOP docshells in the tree?
Assignee | ||
Comment 3•3 years ago
|
||
Reading my last comment back it's a little less understandable than I was hoping. Basically I'm trying verify my understanding that checking if the parent WindowContext
is the current WindowContext
of its BrowsingContext
is a sufficient proxy for checking if the OOP docshell is unloaded.
Comment 4•3 years ago
|
||
Yeah, that's pretty much right. If it was unloaded, the parent WindowContext
wouldn't be current anymore (and/or any of our ancestors would be discarded). This doesn't handle the case where the cross-process frame is currently running unload
event handlers, but that is only relevant for in-process frames, as running unload
is synchronous(*)
*: JS can spin a nested event loop, but it's still conceptually synchronous.
Updated•3 years ago
|
Assignee | ||
Comment 5•3 years ago
|
||
With fission enabled, walking the docshell tree to find unloaded
parents would stop at the first OOP parent. Instead we now walk
the BrowsingContext
/WindowContext
tree. To still check parents
which are OOP, we take advantage of the fact that a parent
WindowContext
will no longer be the current WindowContext
if
the parent was unloaded. For in process docshell's we additionally
check the docshell directly.
Pushed by smacleod@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/6164e09df60e fix nsDocShell::HasUnloadedParent to work for OOP frames. r=nika
Comment 7•3 years ago
|
||
Backed out for failures at nsDocShell.
The push caused mass failures.
Backout link: https://hg.mozilla.org/integration/autoland/rev/3524c48add1142ccd10b6b114864966ea93b2612
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=311677598&repo=autoland&lineNumber=1586
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=311678033&repo=autoland&lineNumber=752
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=311677365&repo=autoland&lineNumber=1265
Assignee | ||
Comment 8•3 years ago
|
||
(In reply to Atila Butkovits from comment #7)
The push caused mass failures.
Woops, sorry about that!
Will land the fixed up patch after a try run.
Pushed by smacleod@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/0d06bfd1fa94 fix nsDocShell::HasUnloadedParent to work for OOP frames. r=nika
![]() |
||
Comment 10•3 years ago
|
||
bugherder |
Description
•