Closed Bug 1589517 Opened 1 year ago Closed 4 months ago

Make it possible for the parent process to choose a content process to assign a remote <xul:browser> to

Categories

(Core :: DOM: Content Processes, task, P2)

task

Tracking

()

RESOLVED FIXED
81 Branch
Fission Milestone M6b
Tracking Status
firefox81 --- fixed

People

(Reporter: mconley, Assigned: nika)

References

Details

Attachments

(4 files)

This is going to be needed for Picture-in-Picture, which opens up an always-on-top window, and inserts a <xul:browser> that is supposed to run in the same content process as the originating video.

Right now, we use the old sameProcessAsFrameLoader mechanism to pull this off with the originating tab's frameLoader: https://searchfox.org/mozilla-central/rev/ebe492edacc75bb122a2b380e4cafcca3470864c/toolkit/components/pictureinpicture/content/player.js#91

But that's not going to fly with Fission. Any suggestions, Nika?

Flags: needinfo?(nika)

This might work if we establish an opener relationship between the PiP window & the source frame's window. If you do that & the principal matches, it should load into the same process.

Not sure if we have any super handy facilities for this from the parent process, but it shouldn't be too hard to add one if we need it.

Altenatively we could have something like sameProcessAsWindow which takes an inner window id?

Flags: needinfo?(nika)
Blocks: 1575868
No longer blocks: 1576915

mconley says this bug is needed for PiP Fission. PiP blocks enabling Fission in Nightly (M6), so we'll need this bug for M6, too.

Fission Milestone: --- → M6

Tracking for Fission M6b

Where possible, we'd like DocumentChannel to own this process logic, not <xul:browser>.

kmag says he'll need to do something similar for WebExtension BCG.

Fission Milestone: M6 → M6b
Priority: -- → P2

Leaving NI for Nika here as she has an idea for implementing this.

Flags: needinfo?(nika)
Assignee: nobody → nika
Flags: needinfo?(nika)
Status: NEW → ASSIGNED

This attribute will subsume the existing sameProcessAsFrameLoader attribute. It
works by specifying the BrowsingContextGroup which the initial BrowsingContext
in a <browser> should be created within.

Due to bug 1652144, all documents within the same BrowsingContextGroup with the
same remote type will be loaded in the same process, meaning that specifying
both "initialBrowsingContextGroupId" and "remoteType" will cause the initial
about:blank document to be loaded in a specific content process.

This attribute, when combined with the remoteType attribute, should subsume all
callers of sameProcessAsFrameLoader, and also support selecting the same process
as an out-of-process iframe.

This attribute can be used to force non-tab extension browsers to be loaded in
the correct BrowsingContextGroup, and also subsumes the existing
sameProcessAsFrameLoader uses in extension code.

The functionality has been fully subsumed by the new
initialBrowsingContextGroupId attribute, so it is no longer necessary.

Pushed by nlayzell@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/7f5deeecabd4
Part 1: Add initialBrowsingContextGroupId attribute, r=farre
https://hg.mozilla.org/integration/autoland/rev/bed38dcb3c26
Part 2: Add initialBrowsingContextGroupId to sameProcessAsFrameLoader callers, r=mconley,smacleod
https://hg.mozilla.org/integration/autoland/rev/c6bac228345d
Part 3: Add initialBrowsingContextGroupId to extension browsers, r=zombie
https://hg.mozilla.org/integration/autoland/rev/5cdeca6b1feb
Part 4: Remove sameProcessAsFrameLoader, r=zombie,mconley,farre,smacleod
Pushed by malexandru@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/91dcf4dce9e6
Remove unnecessary aSameProcessAsFrameLoader declaration from tabbrowser.js for causing lint failures. a=lint-fix
You need to log in before you can comment on or make changes to this bug.