I'm on macOS with WebRender enabled.

Steps to reproduce:

1. Enable Fission.
2. On any webpage, click on a link to a cross-origin page. For example, from this bugzilla bug, click on this link: https://github.com/enterprise
3. Optionally, check what happens when you navigate back/forward between the two pages.

Expected results:
In non-Fission, the old page is visible for a while until the new page is ready to paint. There is no "nothingness" in between.

Actual results:
In Fission, the entire viewport turns light grey on every navigation across origins. This manifests as a rather distracting flash.

Profile with screenshots: https://share.firefox.dev/3ntQaFB

This is probably related to the lag when tearing down the previous content process & starting up rendering in the new one. The "obvious" fix here would be to keep the old process around until the new process is finished painting, but that has some additional complexity involved due to multiple processes thinking they are active at the same time.

Whatever fix we end up creating for this may end up being connected to our work on bfcache+fission due to requiring multiple nsDocShell instances "active" for a BrowsingContext at the same time. We may need to add something like nsDocumentViewer's mPreviousViewer setup, but with cross-process support.

For historical reference, e10s originally had the same problem: bug 1157941.

As Nika says, the things we need for bfcache support overlap a lot with this; we need to keep content processes active for as long as we keep the page in bfcache. Since we'll have the ability to keep processes around for that, we can keep them alive for shorter periods to cover transitions.

I wonder if we'll see the same transition if we a) have another tab open to the same domain (so the process stays alive), and b) what happens using my process-caching patches.

Having another tab open to bugzilla doesn't avoid the white flash, it appears (not surprised); I suspect that the process caching patch won't help either.

Matt, your review of this problem and recommendations of the best possible solution will be greatly appreciated.
Moving to M8 so it blocks Release experiments instead of blocking Beta experiments.

Pointing to a simpler test-case in case it is useful.

I agree with Nika, I think we're going to have to keep the old process/docshell alive (and still the 'active' docshell for the BC) until the new one finishes paint suppression.

Trying to solve this at the graphics level seems hard, we'd need to do a readback of the old content, so that we can then re-composite that as an image if needed. This should work, but we wouldn't be able to async scroll it or anything in the meantime.

Trying to keep the full set of objects around for a 'real' composite is difficult, since everything is tied to IPC actor lifetimes, and would all get torn down when the old content process goes away.

This also seems the most similar to the solution for e10s, where we kept the PresShell for the old document alive while loading the new one.

It's possible we could do that here, tear down the old DocShell immediately when doing a process switch, but add something to keep just the PresShell/Document/process alive until later. It seems scary to have a PresShell without a DocShell though.

This will most probably require BFCache. Leaving a NI here for Nika to see if there's another way to accomplish this.

This will definitely depend on bug 1696175, but maybe more BFCache work too.

It'd be ideal to get this fixed in M7a instead of M8.

This patch takes a simple approach to avoiding they grey flash involved in
process switching by not updating the nsSubdocumentFrame associated with the
<browser> element until after the new process has painted if the previous
process' browser is being kept alive in the BFCache.

This behaviour seems quite difficult to test using automated testing. When
tested manually it appears to function the majority of the time, however will
still occasionally fail, showing a grey flash.

Leaving a ni? for :emilio to potentially look into this patch in case they can figure out what's going on with the intermittent failures etc.

I'd posit that avoiding the flash most of the time would be a win, if we can't find a way to do better. Or a win until we find a way to do better.

Increasing priority to P2 because fixing this grey flash is important. We won't ship Fission with this bug.

This bug is a hard blocker for Fission M8.

This should pretty much match our non-fission behavior. I found the
original approach of keeping the frameloader from nsSubDocumentFrame
quite hard to get green on try unfortunately, because among other
things, the new frameloader wouldn't get the right viewport sizes /
position / etc.

Depends on D121197

https://treeherder.mozilla.org/jobs?repo=try&revision=c066ad0aace022efd67886ec72e965fabb55218c

https://hg.mozilla.org/mozilla-central/rev/a8a416fa3f14
https://hg.mozilla.org/mozilla-central/rev/3def4d84b1f4