Open Bug 1525903 Opened 1 year ago Updated 5 months ago

Child processes should rarely have BrowsingContext trees entirely without nsDocShells

Categories

(Core :: DOM: Core & HTML, task, P3)

task

Tracking

()

Fission Milestone Future

People

(Reporter: farre, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

No description provided.
Priority: -- → P3

I'm not sure if this is completely true. I could imagine us choosing to have the BrowsingContext tree being reflected into e.g. the Extension process even if there are no Extension frames being loaded in that process, but it's at least true in the general case.

Fission Milestone: --- → M3
Summary: Child processes should never have BrowsingContext trees entirely without nsDocShells → Child processes should rarely have BrowsingContext trees entirely without nsDocShells
Component: DOM → DOM: Core & HTML
Blocks: improve-bc
No longer blocks: browsingcontext
Fission Milestone: M3 → M4
Type: enhancement → task
Depends on: 1553139
Fission Milestone: M4 → M5

NI'ing farre to add more context here when he's back from PTO.

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

To flesh out what's the issue here:

We have site a.com, which has a tree of subframes:

  1. a.com/index.html -> a.com/subframe.html -> a.com/subsubframe.html

One of those subframes navigate to b.com which is oop:

  1. a.com/index.html -> b.com/subframe.html

and then sometime late navigates back to a.com:

  1. a.com/index.html -> a.com/subframe.html -> a.com/subsubframe.html

then there will be a content process for b.com at time 3) that has the browsing context tree for time 2) that is entirely without docshells. This isn't wrong, but probably way from optimal.

Flags: needinfo?(afarre)
You need to log in before you can comment on or make changes to this bug.