Open Bug 1580674 Opened 4 months ago Updated 2 months ago

Fix usage of nsIDocShellTreeItem in nsDocShell::GetInheritedFrameType

Categories

(Core :: DOM: Navigation, defect, P2)

defect

Tracking

()

Fission Milestone M6

People

(Reporter: djvj, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [rm-docshell-tree-item:sync-state])

https://searchfox.org/mozilla-central/rev/a777ff11b6d700a698c61e5bd17e73b044304494/docshell/base/nsDocShell.cpp#13171

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.

Fission Milestone: --- → M5
Priority: -- → P2
Whiteboard: [rm-docshell-tree-item:simple]
Fission Milestone: M5 → Future

Kannan says replacing nsIDocShellTreeItem calls should block enabling Fission in Nightly (M6).

Fission Milestone: Future → M6
Whiteboard: [rm-docshell-tree-item:simple] → [rm-docshell-tree-item:sync-state]
You need to log in before you can comment on or make changes to this bug.