Open Bug 1677324 Opened 6 months ago Updated 3 days ago

[Fission] White / grey flash when navigating across origins

Categories

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

All
macOS
defect

Tracking

()

ASSIGNED
Fission Milestone M8

People

(Reporter: mstange, Assigned: nika)

References

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

Details

(Whiteboard: fission-design-needed)

Attachments

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

Fission Milestone: --- → ?

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.

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
Status: NEW → ASSIGNED
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.

You need to log in before you can comment on or make changes to this bug.