(In reply to Andrew Swan [:aswan] from comment #5)
Before diving too deeply into this, I noticed that the commit message for
mentions: "Project Fission's upcoming rewrite of how the DOM requests new content processes."
Jed, is there work planned for Fission that would make this bug irrelevant?
That comment didn't age well. What I'm currently hoping to accomplish is more like what I removed in that commit than what I added: rework how IPC manages OS resources so that we don't need the process's id/handle just to serialize and enqueue a message. That would remove the distinction between sync and async launch: launching will have a sync API but won't block. But that's not a small project, and it's still in the process of being planned.
An alternative that we'd considered was to use the current promise-based “async launch” for subframes, and rely on more or less the current pre-launching for top-level documents. That's simpler, but it doesn't help anything that's launched at startup, like WebExtensions (or non-content processes like the GPU, of course).