Firefox locks up starting at v91 with WebRender on Sway 1.6+

[mvdan]

This issue is split up from #6147. I've only been able to reliably reproduce it via the transparent/missing popups described in that issue. I'm running two displays with mixed resolutions and DPIs, which also seems necessary to trigger 6147.

This bug started happening on Sway 1.6.1 and wlroots 0.14.1 after I upgraded from Firefox 90.0.2 to 91.0 on Arch Linux.

I tried upgrading both sway and wlroots to their current master versions (f67ed67 and swaywm/wlroots@ad7651a) and the bug is still reproducible.

The only way I've managed to stop making this bug reproduce, besides downgrading Firefox, is to force-disable WebRender by enabling gfx.webrender.force-disabled. After restarting the browser, popups still mostly don't work, but I can no longer get the UI to lock up.

Here are the smallest reproduction steps I've been able to find:

1. Setup as above; Sway 1.6.1, Firefox 91.0, WebRender enabled, Firefox running without xwayland. Dual monitors with mixed DPIs to trigger the broken popups.
2. Start Firefox. Open two tabs on different web pages. Switching between the tabs works normally.
3. Open a UI popup or dropdown, such as the settings menu at the top right. It should not be visible, as per 6147.
4. Immediately after, click on the tabs to switch between them. The UI starts locking up; switching tabs doesn't change the page content.
5. Switching windows, or moving the mouse between displays, temporarily makes the Firefox window redraw properly.
6. Changing tabs remains "locked up" until one closes all tabs and starts the browser again.

I also captured a WAYLAND_DEBUG=1 firefox log of me reproducing this issue as per the steps above, on Sway master: firefox_wayland_debug.txt

The fact that this issue reproduces with #6147 makes me think they are related or have the same root cause. But they are not the same user-visible bug: I've been having "missing popups" for over a year, while this lock-up issue only started happening since yesterday, when I upgraded to Firefox 91.

#6322 also sounds similar, but I think is a different issue. My about:support says that WEBRENDER_COMPOSITOR is "Disabled by default" and "Blocklisted by gfxInfo".

[rmader]

Can you try FF nightly? There is a lot going on in the Wayland backend and there's a good chance that things got fixed already - especially if you run in combination with Sway master.

[mvdan]

@rmader sure, can do. Should I try Firefox nightly on Sway master, on Sway 1.6.1, or both? Both would be more work, so I'm wondering which of the two is best. Normally I'd be on Sway stable - right now I'm on master for the same reason, to see if this bug has been fixed on their end since the last release.

[emersion]

In general trying Sway master with Firefox nightly is more helpful, since these contain the latest changes/fixes.

[mvdan]

I created a new profile with Nightly 93.0a1, and I cannot reproduce this issue, even though I fiddled with popup menus and tabs for a solid ten minutes. Weirdly enough, I cannot reproduce #6147 either, which was how I was reproducing this issue to begin with.

I also created a new profile with 91.0 to double check, and I still can reproduce both issues there.

I also downloaded 92.0b2 and repeated the whole process with a new profile. Still cannot reproduce. So my best guess is that some wayland changes were made between 90 and 91 that introduced this issue, and then the wayland changes between 91 and 92 seemingly fixed this issue as well as the long-standing "missing popups" one :)

I even went as far as installing one of my extensions which uses popups, UBlock Origin, and its popups work perfectly on 92.0b2 while they almost never work on 90/91.

[mvdan]

I spoke too soon. The addon popups still mostly don't work; they just appear to work slightly more often than before, and I guess I got lucky. So both beta and nightly still reproduce 6147, but the good news is that they still don't reproduce the lockups here, in 6432.

Another example of a popup UI that doesn't work on any of the three versions is HTML <select> dropdowns.

[hedgepigdaniel]

This is fixed in my case by patching GTK as in https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3898

Also fixes #6147, #6426

[kris7t]

I also tried applying the patch https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3898 suggested by @hedgepigdaniel. It allowed firefox to start with gfx.webrender.compositor.force-enabled, but many visual glitches appeared (scrollbar only partially updated when scrolling, the tree style tab lagged before updating, part of the text in the address bar became invisible when typing). After disabling the WebRender compositor, Firefox stared acting normally again.

I'm running Arch Linux with

wlroots-git 0.14.0.r171.gbfc69dec-1
sway-git r6750.daaec72a-1
gtk3 1:3.24.30+29+gfe19b20492-1 (rebuilt with the patch applied)
firefox 91.0.2-1

[tobiasjakobi]

This is fixed in my case by patching GTK as in https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3898

Also fixes #6147, #6426

I applied the patch to my setup, but it doesn't fix anything for me. The main dropdown menu (from where you can e.g. access the settings) does not show up, neither does the UBlock dropdown menu.

Context menu sometimes shows up, but most of the time in a completly different place where it was opened.

Using:

• firefox 91.0.2
• sway 1.6.1
• wlroots 0.14.0

I have switched to Chromium for the time being, since this behaviour makes FF pretty much unusable.

[acityinohio]

I too am having this issue on FF92 on latest Manjaro stable with sway 1.6.1 — one weird workaround I've noticed (without changing anything else) is that if I disable HiDPI scaling (ie 'swaymsg "output * scale 1"') the context menus show up and the slowdown ceases completely. Not sure if that helps debugging but figured I would mention it to see if that helps anyone else.

[nolanl]

The upgrade to Firefox 93 today fixed this for me.

https://bugzilla.mozilla.org/show_bug.cgi?id=1730476

[rpigott]

Is this still reproducible w/ the gtk patches in #6147?

[mvdan]

I stopped using mixed DPIs in late summer, which worked around this bug. I haven't used mixed DPIs since, so I can't say for sure whether the bug is fixed for good. It does seem to me like the bug is fixed, as the activity in this thread has died down. Thanks again for all your hard work, @rpigott :)

[mvdan]

Closing per the above.