Open Bug 1587425 Opened 1 year ago Updated 4 months ago

Fix usage of nsIDocShellTreeItem in nsContentUtils::SetFocusInner

Categories

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

defect

Tracking

()

Fission Milestone Future

People

(Reporter: djvj, Unassigned)

References

(Blocks 1 open bug)

Details

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

https://searchfox.org/mozilla-central/rev/7cc0f0e89cb40e43bf5c96906f13d44705401042/dom/base/nsFocusManager.cpp#1190

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

DocShell->IsInUnload
DocShell->IsBeingDestroyed
DocShell->IsInActiveWindow

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.