MOZ_ENABLE_WAYLAND=1 mozregression --good 2020-11-12 --pref "gfx.webrender.software:true"

Going to basically any web page (including about:support) makes the browser unresponsive to user input - scrolling the page doesn't work, etc.

28:22.70 INFO: No more integration revisions, bisection finished.
28:22.70 INFO: Last good revision: 5c8f76f41e4ee8c3394cb75bac868312b6d5b6f6
28:22.70 INFO: First bad revision: 773f06221b1b1fa04d2dc0c6acefe61b4be7a5b8
28:22.70 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5c8f76f41e4ee8c3394cb75bac868312b6d5b6f6&tochange=773f06221b1b1fa04d2dc0c6acefe61b4be7a5b8

Set release status flags based on info from the regressing bug 1685055

Martin, could you look at it before the merge to beta next week? Thanks

Sure. Asif, do you see that with basic compositor too?

Martin, the issue is occurring in Basic as well. Standard WebRender is unaffected.

Can you run Firefox on terminal with Waland log enabled:

MOZ_LOG="WidgetWayand:5" firefox

and check where does it wait?

Do you see the missing response only after start or is that bug present with browsing?

I think I saw something similar already. It looked like Firefox works on background (page elements can be clicked on) but web/UI was not updated. But popup windows worked so hamburger menu opened when I clicked on it. Can you confirm such behavior or do you see something different?

Martin, I can't really use the browser in basic or sw-wr modes as it is unusable shortly after beginning to browse.

It looked like Firefox works on background (page elements can be clicked on) but web/UI was not updated. But popup windows worked so hamburger menu opened when I clicked on it. Can you confirm such behavior or do you see something different?

I see this as well. I can reproduce it reliably by navigating to apple.com and scrolling up and down a few seconds. I am able to use the hamburger menu to open new windows, for example.

In the attached log, I opened the browser in basic mode, navigated to apple.com, scrolled up and down, encountered the browser getting stuck, then used the hamburger menu to open a new window and navigated to apple.com in the new window and repeated the issue.

Hope this helps!

Thanks. I tried with latest nightly but without luck. Can you try again and cut the log when the freeze happens? I need to see an exact place in the log when the freeze happens.

Martin, I stopped Firefox (using control-c) in the attached log as soon as I encountered the issue. Hope this helps!

Thanks. Unfortunately I don't see anything wrong there...can you try to open Firefox on one window and open a terminal with the log along it and see if the log is updated while Firefox is frozen? According the log there isn't any freeze or so. I'd expect waiting for Wayland Buffer or so.

The log doesn't stop when Firefox is frozen. The only time the log stops is when I fullscreen GNOME Terminal and Firefox is in the background. If I bring Firefox back to the foreground, the log resumes.

(In reply to Asif Youssuff from comment #13)

The log doesn't stop when Firefox is frozen. The only time the log stops is when I fullscreen GNOME Terminal and Firefox is in the background. If I bring Firefox back to the foreground, the log resumes.

Thanks! That means Firefox actually paints the web content but compositor does not show it. I inspected the log and the buffers seem to be attached correctly. Can you please try to dump wl_buffers which Firefox sends to compositor? And please use basic compositor, not sw-wr one.

Run Firefox on terminal as:

MOZ_WAYLAND_DUMP_WL_BUFFERS=1 MOZ_ENABLE_WAYLAND=1 firefox

You should have *.png files in your current working dir, the images contains painting which is send by Firefox to compositor. Please check if the screens are correct, i.e. there's some content which is expected to be painted (but the painting from some reason fails as you see).

Also which mutter version do you run?

Thanks.

Martin, running in Basic mode and with MOZ_WAYLAND_DUMP_WL_BUFFERS=1 runs very slowly and doesn't appear to stop responding. The browser remains responsive after a minute or two (while saving hundreds of images), unlike when dumping buffers is enabled.

The screenshots seem fine and correspond to what I see on the screen.

mutter-common is 3.38.2-1ubuntu1 - I am running a live session, so it is a consistent environment. mutter is not installed.

Thanks Asif. Right now I'm out of idea what can cause it...it's also interesting that you can reproduce it reliably.
Maybe Wayland log can help. Please run Firefox as:

WAYLAND_DEBUG=1 MOZ_LOG="WidgetWayand:5" firefox

that will produce the wayland+widget log. Please leave it running for a short time when it's frozen (say 5 sec) and then quit the browser. I'd need to have the log small for better readability.

Thanks.

Martin, I took two logs because I was unsure if you wanted me to quit via Control-q or by exiting the app from the terminal it was launched from (Control-c).

Please see attached logs:

quit.txt.moz_log - quit using control-q
force-quit.txt.moz_log - quit from terminal using control-c

Hope this helps!

Depends on D103185

Thanks. From the log it looks like we're not getting new buffers so the painting is cached. But I'd need more log info so I did more logging to the buffer management code. I'll ask you for another log when the patch here is in nightly.
Thanks.

https://hg.mozilla.org/mozilla-central/rev/59e780d9359a
https://hg.mozilla.org/mozilla-central/rev/466211e554bc

Asif, can you please provide log from latest nightly? It contains extra logging for the missing buffers.
Thanks.

(In reply to Martin Stránský [:stransky] from comment #25)

Asif, can you please provide log from latest nightly? It contains extra logging for the missing buffers.
Thanks.

Martin, sure.

I took two logs because I was unsure if you wanted me to quit via Control-q or by exiting the app from the terminal it was launched from (Control-c).

Command used:

MOZ_LOG_FILE="log.txt" MOZ_ENABLE_WAYLAND=1 WAYLAND_DEBUG=1 MOZ_LOG="WidgetWayland:5" ./firefox/firefox

Please see attached logs:

quit.txt.moz_log - quit using control-q
force-quit.txt.moz_log - quit from terminal using control-c

Hope this helps!

Thanks. The control-c from terminal is better. I did some painting rework at Bug 1667851 and I'll look at this one then.

https://hg.mozilla.org/mozilla-central/rev/05098560d311

Comment on attachment 9201124 [details]
Bug 1687212 [Wayland] Set mAttached flag before wl_surface_commit() to avoid potential race condition, r?jhorak

Beta/Release Uplift Approval Request

• User impact if declined: Freezes on Wayland backend.
• 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): Only reorder commit flag setting to set it before it's checked.
• String changes made/needed:

Comment on attachment 9201124 [details]
Bug 1687212 [Wayland] Set mAttached flag before wl_surface_commit() to avoid potential race condition, r?jhorak

Low risk for mozilla builds as we don't ship Wayland by default officially yet, approved for 86 beta 8, thanks.

https://hg.mozilla.org/releases/mozilla-beta/rev/45beb340a539