Open Bug 1580601 Opened 5 years ago Updated 2 years ago

Fix usage of nsIDocShellTreeItem in nsDocShell::InternalLoad

Categories

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

Product:
Core
Component:
DOM: Navigation
Type:
defect

Tracking

()

Project Flags:
Fission Milestone Future

People

(Reporter: djvj, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [rm-docshell-tree-item:hard])

Two uses, the first is more significant.

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

Here, InternalLoad gets the parent docshell (any type), and if it exists, gets the document from it and calls TryCancelFrameLoaderInitialization() on it.

This has to be checked for OOP parent, an if so forwarded to the appropriate process.

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

This usage is a much simpler fix. It occurs within #ifdef DEBUG code, retrieves the parent and asserts that it is null. Just needs to be changed to use BrowsingContext tree instead to check existence of a (same-type) parent.

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

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

Fission Milestone: Future → M6

This is only relevant in the in-process case, as we will never be in this situation when across process boundaries. This code is only relevant due to timing of frame loader initialization.

Blocks: rmrf-docshell-tree-item
No longer blocks: rm-docshell-tree-item
Fission Milestone: M6 → Future
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.