Open Bug 1587425 Opened 2 years ago Updated 1 year ago

Fix usage of nsIDocShellTreeItem in nsContentUtils::SetFocusInner


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




Fission Milestone Future


(Reporter: djvj, Unassigned)


(Blocks 1 open bug)


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

This accesses a bunch of state that needs to be synchronized to BrowsingContext, namely:


None of these fields should be mutated heavily, and synchronizing this state should not be too much of an overhead.

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

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

Fission Milestone: Future → M6

I don't think we need to sync those particular fields onto the BrowsingContext object. We can probably get away with a less precise mechanism in the cross-process case.

ni? :hsivonen, as this is related to his work with focus when Fission is enabled.

Flags: needinfo?(hsivonen)

The main reason to keep using nsIDocShellTreeItem for the focus code in chrome process is that there's intentionally no way to walk from a content BrowsingContext up to a chrome BrowsingContext, but the focus code in the chrome process, IIRC, wanted to walk from a content nsIDocShellTreeItem up to a chrome nsIDocShellTreeItem.

Flags: needinfo?(hsivonen)

Auditing whether this use of nsIDocShellTreeItem breaks when Fission is enabled blocks Fission Nightly.

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