1762098 - [wayland] Hover and drop down menus in Firefox's UI do not close in Gnome (with webrender compositor force-enabled)

Status: RESOLVED DUPLICATE of bug 1752678

(Core :: Widget: Gtk, defect)

Description

[theodonacik]

Attachment: Screenshot from 2022-03-29 22-50-18.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:100.0) Gecko/20100101 Firefox/100.0

Steps to reproduce:

Installed Firefox Nightly, log into Gnome DE, then hover over tabs, click the menu in upper right or lock icon in address bar

Actual results:

The resulting menus do not go away visually, even after clicking off them moving the window. Firefox must be restarted. Still occurs in safe mode.

Expected results:

These menus should disappear. This behavior is not shared in either Sway WM and in Firefox non-nightly.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Huh, I use gnome and I can't reproduce, can you attach your about:support information? Did this work before (I hope so)?

Comment 3

[theodonacik]

Attachment: about:support

Comment 4

[theodonacik]

I have not noticed this issue before, but I when I used gnome previously I used the non-nightly version which works fine, and with nightly in Sway this does not happen either. This may be related to the gnome 42/Fedora 36 update, but I cannot confirm as I did not use this version of Firefox in gnome before I updated

Comment 5

[Emilio Cobos Álvarez (:emilio)]

That's odd because I run Rawhide and well, things are usually much more broken than on the regular Fedora release ;-)

Could you run the following and see if it works there? It's just running a nightly from the 98-release-timeframe (MOZ_ENABLE_WAYLAND=1 shouldn't be needed I think, but better safe than sorry):

$ pip3 install --user mozregression
$ MOZ_ENABLE_WAYLAND=1 mozregression --launch 98

If that is working properly, can you run:

$ MOZ_ENABLE_WAYLAND=1 mozregression --good 98

That should give us a regression range on your machine. With a good internet connection it should not take more than 15 minutes, if you could do that it'd be amazing.

If that is not working properly that smells like a bug in Mutter, but...

Comment 6

[theodonacik]

It only showed me two versions before it errored because the build for 2022-03-30 good when it was expected to be bad. It seems to be only an issue with some configuration about what I have installed, which is strange because the issue persists even when I launch it in troubleshoot mode.

Comment 7

[Emilio Cobos Álvarez (:emilio)]

Yeah that means some pref in your profile is causing it. It seems you have settings like gfx.webrender.compositor.force-enabled=true and so on. Does toggling that back off help?

Comment 8

[theodonacik]

Yes, toggling gfx.webrender.compositor.force-enabled to false fixed the problem, thank you.

Comment 9

[Garrett LeSage]

I'm hitting this pretty invasive bug on freshly-release stable Firefox 99, as a Flatpak (the official one on Flathub), on Fedora 36 beta's GNOME 42 Wayland session.

Toggling gfx.webrender.compositor.force-enabled to false and activating the menu again allowed it to go away once, but it came back even with that setting enabled. (I haven't restarted Firefox yet, however, as I'm in the middle of doing work.) I think that means it's intermittent, but mainly stuck?

Trying to dismiss the menu by calling it up in other browser windows just makes multiple copies of the menu show up — one per window. Whoops.

Comment 10

[Emilio Cobos Álvarez (:emilio)]

changing gfx.webrender.compositor.force-enabled requires a restart.

Comment 11

[Garrett LeSage]

I've finished my meeting, saved my work in other tabs, and restarted my browser. WebRender is still enabled according to about:support (no surprises there), but the force-enabled setting is set to false (default) and I haven't managed to trigger the lingering menu bug yet.

So far seems this bug is related to forcing WebRender on, but not WebRender itself? (Or it's one of those bugs that only shows up under certain conditions.)

Thanks for the suggestion about turning off the force and restarting! So far, so good!

Comment 12

[Emilio Cobos Álvarez (:emilio)]

Force-enabling WebRender is different from force-enabling the WebRender compositor. The WebRender compositor is default-off, afaict.

Comment 13

[sven.pilz]

I have the same issue on Arch with Gnome 42. Also had gfx.webrender.compositor.force-enabled set to true. Resetting the value solved the issue.

Comment 14

[bbhtt]

Duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1752678