Open Bug 1575321 Opened 5 months ago Updated 2 months ago

Fix usage of nsIDocShellTreeItem in nsDocShell::Destroy

Categories

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

enhancement

Tracking

()

Fission Milestone M6

People

(Reporter: djvj, Unassigned)

References

(Blocks 1 open bug)

Details

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

https://searchfox.org/mozilla-central/source/docshell/base/nsDocShell.cpp#4918

Here, the destroy code calls RemoveChild on the parent docshell, referenced directly from mParent. The parent may be null in post-fission semantics, if it's out of process.

The destroy code should detach the parent if it exists, but additionally also detach the corresponding BrowsingContext from its parent BrowsingContext.

Component: DOM: Core & HTML → Document Navigation

Check if this bug is still valid or got fixed by andreas.

Flags: needinfo?(kvijayan)
Fission Milestone: --- → M5
Priority: -- → P2

Andreas - is there a bug for the overall fission docshell destroy work I can link this to? Has that work landed or is it still in progress?

Flags: needinfo?(kvijayan) → needinfo?(afarre)
Whiteboard: [rm-docshell-tree-item:hard]

I think that this now is the bug for the overall fission docshell destroy work! :D

Generally I'm not very happy with how nsDocShell::Destoy works, and something that I think we need to clean up. Today, nsDocShell::Destroy drives much of BrowsingContext tear down as well, which isn't super-ideal.

This is definitely work in progress, but more on a needs basis, than a focused effort.

Flags: needinfo?(afarre)
Fission Milestone: M5 → Future

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

Fission Milestone: Future → M6
You need to log in before you can comment on or make changes to this bug.