1580153 - Fenix loading blank pages with webRender on

Status: VERIFIED FIXED

(Core :: Graphics: WebRender, defect, P3)

Description

[Oana Horvath [:ohorvath]]

Attachment: 20190910_074957.gif

Steps to reproduce:

1. In about:config switch gfx.webrender.all to "True" and restart the browser.
2. Load a few tabs in Fenix.
3. Switch between tabs.

Expected results:
Every page is displayed.

Actual results:
Some tabs are blank until you scroll the page a little. Some don't load at all, you need to switch tabs a few times to eventually see the page.
recording attached.

device: Pixel 2 (Android 9), Fenix build: Nightly 9/10, GV 71

Comment 1

[Jessie [:jbonisteel] pls NI]

Jamie, curious if you can reproduce this?

Comment 2

[Jamie Nicol [:jnicol] (on leave until 21st October)]

Yes I can reproduce this. Interestingly while I can reproduce in fenix and the reference browser, I cannot in the geckoview example app

When we switch away from a tab, geckoview covers the widget in white. Then when it is notified that we've rendered the first frame for a new tab, it uncovers the widget. For some reason this first paint notification isn't getting through.

You can see that the new tab is indeed being rendered: If you switch app, in android's app switcher the content of the tab is briefly visible, as the white covering doesn't seem to be rendered during the app switch animation.

Comment 3

[Jamie Nicol [:jnicol] (on leave until 21st October)]

Attachment: Bug 1580153 - Call NotifyFirstPaint on next composite after RecvResumeAndResize. r?jrmuizel

Previously after RecvResumeAndResize() we would set a flag on the root
WebRenderBridgeParent, which in turn sets a flag on the next display list it
receives that it should be treated as a first paint. Then when that display list
is finally composited, we call UiCompositorControllerParent::NotifyFirstPaint(),
which in turn tells GeckoView to uncover the widget.

After switching tabs in GeckoView browsers, however, the root
WebRenderBridgeParent does not always receive a new display list, so the widget
would not be uncovered. Instead of waiting for the next received display list to
be composited, we simply want to uncover the widget on the next composite. To
achieve this we instead set the forced-first-paint flag on the root
CompositorBridgeParent then we call NotifyFirstPaint() during
CompositorBridgeParent::NotifyPipelineRendered().

Comment 4

[Jamie Nicol [:jnicol] (on leave until 21st October)]

So the problem here seemed to be that when we RecvResumeAndResize we set the first paint flag on the root WebRenderBridgeParent, which in turn sets it on the TransactionId during the next RecvSetDisplayList. Only when that display list is finally composited and flushed do we uncover the window by calling NotifyFirstPaint. The problem is that when switching tab, the root WebRenderBridgeParent doesn't always receive a new display list. The non-root WRBP does seem to, but the root display list bails out early in the layout painting code, so it never sends a transaction to the WebRenderLayerManager.

Me and Jeff discussed this and decided to store the flag on the CompositorBridgeParent, and call NotifyFirstPaint on the next composite. This seems to fix the tab switching issue. However, we still feel this is not quite right. We've noticed sometimes the screen is black after restoring the app (bug 1581868) which could be related.

However, we will land this for now as it is an improvement. And can keep trying to figure it out afterwards.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1bb4b33f057f
Call NotifyFirstPaint on next composite after RecvResumeAndResize. r=jrmuizel

Comment 6

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/1bb4b33f057f

Comment 7

[Oana Horvath [:ohorvath]]

about:config doesn't work anymore on Fenix, so I'm not able to verify this yet, as I need to switch the toggle.

Comment 8

[Oana Horvath [:ohorvath]]

This was verified today on Nightly 9/27.