Open Bug 1575321 Opened 3 years ago Updated 3 years ago

Fix usage of nsIDocShellTreeItem in nsDocShell::Destroy


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




Fission Milestone Future


(Reporter: djvj, Unassigned)


(Blocks 1 open bug)


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

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

The BrowsingContext destroy work has generally been disconnected from the lifecycle of the nsDocShell since bug 1582832. The remaining work mentioned in this bug is just related to removing a user of nsIDocShellTreeItem related to nsIDocShellTreeItem lifecycles. Moving to future.

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