1798714 - [Bug]: Web content is not displayed if `gfx.webrender.software` is `true`

Status: VERIFIED FIXED

(Core :: Graphics: WebRender, defect)

Description

[Jamie Nicol [:jnicol]]

From github: https://github.com/mozilla-mobile/fenix/issues/27039.

Steps to reproduce

Multiple STRs...

1. Set default browser to Firefox Nightly

2. Open link from another application

3. Select a tab in the tab tray whose domain has not been loaded

etc. I guess the bug happens when I try to open a web page whose domain hasn't been loaded.

Expected behaviour

The web content should be painted.

Actual behaviour

The web content is not painted, if I see a tab, then, the tab's content is not erased and new tab's content is not painted, and if I open a link from another app, the web contained painted as black.

Device name

Galaxy Tab S8+

Android version

Androine 12, One UI 4.1

Firefox release type

Firefox Nightly

Firefox version

106.0a1

Device logs

No response

Additional information

I guess that I hit a bug of GPU driver of Galaxy S8+ or a GPU process's bug of Gecko because after I switched to another tab, the buggy tab is painted correctly (and when it's painted as black, tapping somewhere probably over a link loads another page. In addition, I don't reproduce this on Pixel 5a5G.

IIRC, I started to reproduce this bug since around 21st August. I tried to collect some warnings or errors, but I couldn't have a chance to get it so that I delayed to reported this.

┆Issue is synchronized with this Jira Task

Change performed by the Move to Bugzilla add-on.

Comment 1

[Jamie Nicol [:jnicol]]

What's happening is that the SWGL compositor is refusing to composite because BeginFrameForWindow() returns Nothing here. This is because mSurfaceSize is 0x0 here. The surface size comes from AndroidCompositorWidget::mClientSize. Prior to bug 1783542, we queried this value from the ANativeWindow whenever the compositor was resumed. However, that patch made us instead use the value we are passed from the UI thread via UiCompositorControllerChild->ResumeAndResize().

Usually this gets called from here. However, there is a race condition. If SyncResumeResizeCompositor() is called prior to the compositor being created, then mUiCompositorControllerChild will be null and we do not call ResumeAndResize(). Instead, we wait until NotifyCompositorCreated() gets called, but as you can see here, this only calls mUiCompositorControllerChild->Resume() rather than mUiCompositorControllerChild->ResumeAndResize(). So the AndroidCompositorWidget's size never gets updated, and remains 0x0.

To fix this, we can simply change that call to ResumeAndResize() rather than Resume(). We have the width and height values cached anyway.

Comment 2

[Jamie Nicol [:jnicol]]

Attachment: Bug 1798714 - Ensure compositor is always resumed with correct size on Android. r?#gfx-reviewers

On Android when SWGL is enabled, occasionally when switching tabs it
refuses to render the new tab. The user will instead be left with the
contents of the previous tab, or if they have just switched to firefox
they will be left with a black screen.

This occurs when SyncResumeResizeCompositor is called from java code
prior to the gecko compositor having been created. This results in us
delaying the call to UiCompositorController::ResumeAndResize().
Instead, once the compositor eventually gets created we call
UiCompositorController::Resume() (without the resize).

This means that the compositor widget is left with a zero size, and
RenderCompositorLayersSWGL bails early on compositing as a result.

To fix this, we cache the X, Y, width, and height arguments passed to
SyncResumeResizeCompositor. Then to resume the compositor when it
eventually gets created, we call ResumeAndResize() with the cached
values, rather than just calling Resume.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/46777938a472
Ensure compositor is always resumed with correct size on Android. r=gfx-reviewers,geckoview-reviewers,calu,jrmuizel

Comment 4

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/46777938a472

Comment 5

[Jamie Nicol [:jnicol]]

Comment on attachment 9301571 [details]
Bug 1798714 - Ensure compositor is always resumed with correct size on Android. r?#gfx-reviewers

Beta/Release Uplift Approval Request

• User impact if declined: Sometimes when opening a link from another app, or switching to an unloaded tab, some users will be left with a frozen page
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Small change. Makes us consistently use the same function to resume the compositor, so that when we hit this rare race condition we use the same well-tested path as in the normal case.
• String changes made/needed:
• Is Android affected?: Yes

Comment 6

[Donal Meehan [:dmeehan]]

Comment on attachment 9301571 [details]
Bug 1798714 - Ensure compositor is always resumed with correct size on Android. r?#gfx-reviewers

Approved for Desktop 107.0b9 and Fenix/Focus 107.0b6

Comment 7

[Donal Meehan [:dmeehan]]

https://hg.mozilla.org/releases/mozilla-beta/rev/3f1cd4207bf9

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

It seems that I don't reproduce this anymore, and I reproduced similar bug in a couple of days without enabling gfx.webrender.software, but it seems that it's also fixed by this. Thank you very much!