Fix usage of nsIDocShellTreeItem in nsDocShell::GetInheritedFrameType
Categories
(Core :: DOM: Navigation, defect, P3)
Tracking
()
| Fission Milestone | Future |
People
(Reporter: djvj, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [rm-docshell-tree-item:sync-state])
So this function walks up the docshell tree (same-type only) looking for a BROWSER frametype, and if it finds one it returns it, otherwise returns REGULAR.
Looking at the usage of mFrameType, it does seem like this value can change up the tree at runtime, via SetFrameType, which is called by nsFrameLoader::MaybeCreateDocShell and BrowserChild::UpdateFrameType.
This property is not sensitive enough to require quarantining within the process.
I ignored MaybeCreateDocShell because the property being set at docshell creation time is forwardable to children.
The other case (BrowserChild::UpdateFrameType), only seems to be called in the code path for swapping frame loaders. I'm not sure when or why frame loaders get swapped yet, and I tried to look deeper into whether swapping frame loaders allows us to discount the possibility of child docshells existing, but didn't find anything conclusive.
This flag seems like it can be cached in BrowsingContext, and propagated down the tree eagerly as an inherited constant.
This does seem like a bit of work.
|
||
Updated•5 years ago
|
|
Reporter | |
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
|
||
Comment 1•5 years ago
|
||
Kannan says replacing nsIDocShellTreeItem calls should block enabling Fission in Nightly (M6).
|
|
Reporter | |
Updated•5 years ago
|
|
||
Comment 2•4 years ago
|
||
This method is used to determine if the document is loaded within an <iframe mozbrowser>. In bug 1614462, :kmag is removing support for loading mozbrowsers within content processes, meaning that this code can only return a non-REGULAR frame type within the parent process.
|
||
Comment 3•4 years ago
|
||
This method has been removed by https://hg.mozilla.org/mozilla-central/rev/3c37d27ef0af
Description
•