Closed Bug 1677324 Opened 4 years ago Closed 3 years ago

[Fission] White / grey flash when navigating across origins


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




92 Branch
Fission Milestone M8
Tracking Status
firefox-esr78 --- disabled
firefox-esr91 --- disabled
firefox89 --- disabled
firefox90 --- disabled
firefox91 --- disabled
firefox92 --- fixed


(Reporter: mstange, Assigned: emilio)


(Depends on 1 open bug, Blocks 1 open bug, )


(Whiteboard: fission-hard-blocker)


(2 files, 1 obsolete file)

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:
  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.

Fission Milestone: --- → ?

Profile with screenshots:

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.

Severity: -- → S3
Priority: -- → P3
Fission Milestone: ? → M6c
Fission Milestone: M6c → M7

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.

Fission Milestone: M7 → M8
Flags: needinfo?(matt.woodrow)

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.

Flags: needinfo?(matt.woodrow)

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.

Whiteboard: fission-design-needed

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

Flags: needinfo?(nika)
Depends on: fission-bfcache

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

Depends on: 1696175

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

Fission Milestone: M8 → M7a
See Also: → 1699768
Fission Milestone: M7a → M8
Assignee: nobody → nika
Flags: needinfo?(nika)

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.

Flags: needinfo?(emilio)

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.

Assignee: nika → emilio

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.

Whiteboard: fission-design-needed → fission-hard-blocker

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

Flags: needinfo?(emilio)
Pushed by
Add the ability for subdocuments to keep painting another remote subdoc. r=mattwoodrow
Keep painting the of the old remote frame when going into the bfcache until the child unsuppresses painting. r=nika
Regressions: 1723439
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 92 Branch
Blocks: 1723495
Regressions: 1725384
Attachment #9221377 - Attachment is obsolete: true
See Also: → 1740499
You need to log in before you can comment on or make changes to this bug.