STR:

1. Run with MOZ_ENABLE_WAYLAND=1 and gfx.webrender.software = true on Ubuntu 20.10.
2. Open multiple youtube videos in Picture-in-Picture.
3. Continuously resize the main browser window for several minutes until it stops responding.

It can also occur after a few hours of browsing but it is much faster to reproduce with video.

The following terminal error sometimes occurs when the window is resized or when a video is scrolled out of view:

[GFX1-]: RenderCompositorSWGL failed mapping default framebuffer

Attached is log output for WAYLAND_DEBUG=1 MOZ_LOG="WidgetWayland:5".

Can you please try latest nightly?
Thanks.

It still happens on latest Nightly 88.0a1 (20210303215027) with SW-WR+Wayland. It does not happen with XWayland or HW-WR.

It also happens with Basic compositor.

Timeline:

2020-12-21: No freezing.
2020-12-22 (Bug 1648698): Freezes when opening a PiP window.
2021-01-13 (Bug 1685055): Freezes soon after startup.
2021-02-05 (Bug 1687212): Freezes after a while (current situation).

Originally regressed by Bug 1648698.

I think I've been experiencing the same bug (on sway compositor), and a workaround that works for me is layers.acceleration.force-enabled = true.

layers.acceleration.force-enabled = true enables OPENGL_COMPOSITING but it still freezes for me on Ubuntu 20.10.

gfx.webrender.software.opengl = true enables "WebRender (Software OpenGL)" which does not have this issue.

That's surprising, I definitely don't have webrender enabled (confirmed in about:support) and the opengl compositing alone fixed it for me. Perhaps we have slightly different bugs.

This got significantly better for me sometime recently. Kestrel, do you still see this?

No change for me, I can still easily freeze Nightly 90.0a1 (2021-04-24) on Ubuntu 21.04 within 10 minutes with several videos playing simultaneously. It never happens with hardware Webrender.

In the console I get these 3 errors, but not sure if one of them is related to the issue:

IPDL protocol error: Handler returned error code!

###!!! [Parent][DispatchAsyncMessage] Error: PMessagePort::Msg_PostMessages Processing error: message was deserialized, but the handler returned false (indicating failure)

###!!! [Parent][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost

I'm currently working on a new software buffer backend in bug 1708416. Can some(one) of you try the following build, which includes the patch among others, with SW-WR? Because I've seen similar behaviour in the past and am not able to reproduce it with that patch any more.

https://treeherder.mozilla.org/jobs?repo=try&revision=1e5ad47989a5b37c2876942a9d9df64130cac193&selectedTaskRun=ccwi_HfJSr22WhM3A3nyjw.0

Direct download: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/ccwi_HfJSr22WhM3A3nyjw/runs/0/artifacts/public/build/target.tar.bz2

(In reply to Robert Mader [:rmader] from comment #10)

I'm currently working on a new software buffer backend in bug 1708416. Can some(one) of you try the following build, which includes the patch among others, with SW-WR? Because I've seen similar behaviour in the past and am not able to reproduce it with that patch any more.

https://treeherder.mozilla.org/jobs?repo=try&revision=1e5ad47989a5b37c2876942a9d9df64130cac193&selectedTaskRun=ccwi_HfJSr22WhM3A3nyjw.0

Direct download: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/ccwi_HfJSr22WhM3A3nyjw/runs/0/artifacts/public/build/target.tar.bz2

I tested your patch using "GDK_BACKEND=wayland ./firefox". After a few hours with around 20 open tabs I ended up with a unresponsive window. The console did not print any warnings or errors when the error occurred.

(In reply to tobias47n9e from comment #11)

I tested your patch using "GDK_BACKEND=wayland ./firefox". After a few hours with around 20 open tabs I ended up with a unresponsive window. The console did not print any warnings or errors when the error occurred.

Thanks a lot for testing. That is super unfortunate, especially if whatever is happening is so hard to reproduce. Just for the record: this was on SW-WR, correct?

I wonder if this has to do with Wayland queue dispatching or something like that. Will try harder to reproduce here.

(In reply to Robert Mader [:rmader] from comment #12)

(In reply to tobias47n9e from comment #11)

I tested your patch using "GDK_BACKEND=wayland ./firefox". After a few hours with around 20 open tabs I ended up with a unresponsive window. The console did not print any warnings or errors when the error occurred.

Thanks a lot for testing. That is super unfortunate, especially if whatever is happening is so hard to reproduce. Just for the record: this was on SW-WR, correct?

I wonder if this has to do with Wayland queue dispatching or something like that. Will try harder to reproduce here.

Not sure if I am using SW-WR or hardware accelerated. I couldn't find that information in about:support

I think starting today I couldn't reproduce the issue. I am currently using: 90.0a1 (2021-05-20).

(In reply to tobias47n9e from comment #14)

I think starting today I couldn't reproduce the issue. I am currently using: 90.0a1 (2021-05-20).

Now using 90.0a1 (2021-05-25) (64-bit) and I could reproduce the last few days. My earlier message was from a day where i fully restarted my PC, so RM usage was low and SWAP was unused. So perhaps the issue only happens in combination with Gnome and the OS running out of memory? Currently my RAM usage is at ~85% and my small SWAP of 1 GB is full.

I've been using SW-WR on Nightly since Comment 10 (2021-05-17) and can no longer reproduce the issue on Ubuntu 20.10 or 21.04 (two computers, no memory constraints, one with swap disabled). I tested earlier builds and while it did occur, it was much more difficult to reproduce than before. This would suggest a combination of improvements in Nightly 90 and upstream that avoids the issue.