1605092 - BrowserBridgeParent::Init should use non-blocking process creation API

Status: RESOLVED WORKSFORME

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

Comment 1

[Chris Peterson [:cpeterson]]

Tracking async process launching work for Fission Nightly (M6)

Comment 2

[David Teller [:Yoric] - still alive but not very active]

Attachment: Bug 1605092 - Introducing BrowserBridgeParent::mPromiseBrowserParent;r?qdot

As part of the ongoing refactoring towards async process launching, I'll need
to make sure that all the APIs of BrowserBridgeParent are async. In the
interest of doing it piece-wise, this is the first step towards making
BrowserBridgeParent::GetBrowserParent async.

Comment 3

[David Teller [:Yoric] - still alive but not very active]

Attachment: Bug 1605092 - Making internal APIs of BrowserBridgeParent implementation async;r?qdot

Depends on D58134

Comment 4

[David Teller [:Yoric] - still alive but not very active]

Attachment: Bug 1605092 - Switching BrowserBridgeParent::Init to use non-blocking process launching;r?qdot

Depends on D58135

Comment 5

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

This might be dead code.

As I understand it, the ContentChild::CreateBrowser → BrowserBridgeParent::Init path was how things used to work for Fission frames, but then bug 1576714 created the CanonicalBrowsingContext::ChangeFrameRemoteness path and moved them to it. Empirically, I can have a breakpoint set on BrowserBridgeParent::Init and load sites with cross-origin iframes in Fission mode and it's never hit.

But I also thought that the plan included deleting this code, and that hasn't happened, and I don't know if that's intentional or if the DOM people just haven't gotten around to it yet.

Nika is the authority on this, but the reviewers from bug 1576714 might also be able to help. (This was briefly discussed on Slack #fission on 2019-11-26, and nobody present seemed to be entirely sure what was going on, and I'd forgotten about it until I saw this bug.)

Comment 6

[David Teller [:Yoric] - still alive but not very active]

Er... ok. I'll check if it's dead code.

If it is, does it mean that the only thing I need to do for async process creation is bug 1605072?

Comment 7

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

(In reply to David Teller [:Yoric] (please use "needinfo") (away December 30th - January 5th) from comment #6)

Er... ok. I'll check if it's dead code.

Sorry to be the bearer of bad news about your patch. (Also, for future reference, qDot is no longer active here and has resigned as a DOM peer.)

If it is, does it mean that the only thing I need to do for async process creation is bug 1605072?

I think so? At this point I'm reduced to browsing searchfox and running with debugger breakpoints to see what gets used for what, but it looks like bug 1605072 covers what Fission iframes use.

Comment 8

[David Teller [:Yoric] - still alive but not very active]

Well, this try push https://treeherder.mozilla.org/#/jobs?repo=try&revision=5fa501b7afc0fe558e3a3928d6b96b9043699934 seems to indicate that the code is indeed dead.

Closing bug!