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

Steps to reproduce:

The issue appears on Arch Linux and Ubuntu 21.10 (both on Wayland).

Either:

• trigger a permission popup and try to close it; or
• open Firefox main menu, close it, then try again.

Actual results:

The permission popup or the menu doesn't disappear, even when switching tabs. Only restarting Firefox makes them disappear.

Expected results:

The permission popup or the menu should disappear.

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.

Can you try latest nightly?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Testing_Mozilla_binaries
Thanks.

I can confirm the issue is fixed in Firefox Nightly 101.0a1 (2022-04-29). Thanks for fixing this!

I tried some other releases to see which release contains the fix -- and curiously even 99.0.1 [1] works.
This should be the same 99.0.1 as what Arch is using in the extra/firefox package [2].
I'm testing the popups by going to https://permission.site
I'm not sure what's different in the Arch version, but it seems this is more of an Arch packaging bug then?

[1] https://download-installer.cdn.mozilla.net/pub/firefox/releases/99.0.1/linux-x86_64/en-US/firefox-99.0.1.tar.bz2
[2] https://github.com/archlinux/svntogit-packages/blob/packages/firefox/trunk/PKGBUILD

The issue is not specific to Arch, I had it on Ubuntu 21.10 as well.

I recently upgraded to Ubuntu 22.04 and the issue is gone. It forced me to switch to the snap package though, I don't know if this is related.

On Arch Linux, the issue seems fixed on Firefox Nightly, at least for the main app menu.

I wanted to add that I am still seeing this issue with firefox 100.0-1 on Archlinux. I also saw it on version 99.0.1. I am using gnome with wayland, and have enabled native wayland rendering in firefox with the MOZ_ENABLE_WAYLAND=1 environment variable. A possibly relevant detail is that my laptop has an odd sized screen, so I have enabled fractional scaling in wayland with the gnome settings key gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']", and use 150% scaling.

This is very easy for me to reproduce, so let me know if there are any tests I can run to help debug. For me, almost any overlay generated by the browser (incluiding hover text or dropdowns) gets "stuck". It seems to be stuck in the browser's buffer, not the system's, since I can switch applications and the menus disappear, but they are still there when I switch back to firefox, and still visible when switching tabs within firefox. I'm happy to provide screenshots if helpful too. I will switch to nightly and see if I have better luck.

environment is:
wayland: 1.20.0-2
mutter: 42.0-2
mesa: 22.0.2-1
gtk4: 1:4.6.3-1
gtk3: 1:3.24.33-3
Processor: 11th Gen Intel(R) Core(TM) i7-1165G7
Graphics: Intel® Iris® Xe Graphics

(In reply to matt.9.johnson from comment #6)

I wanted to add that I am still seeing this issue with firefox 100.0-1 on Archlinux. I also saw it on version 99.0.1. I am using gnome with wayland, and have enabled native wayland rendering in firefox with the MOZ_ENABLE_WAYLAND=1 environment variable. A possibly relevant detail is that my laptop has an odd sized screen, so I have enabled fractional scaling in wayland with the gnome settings key gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']", and use 150% scaling.

This is very easy for me to reproduce, so let me know if there are any tests I can run to help debug. For me, almost any overlay generated by the browser (incluiding hover text or dropdowns) gets "stuck". It seems to be stuck in the browser's buffer, not the system's, since I can switch applications and the menus disappear, but they are still there when I switch back to firefox, and still visible when switching tabs within firefox. I'm happy to provide screenshots if helpful too. I will switch to nightly and see if I have better luck.

environment is:
wayland: 1.20.0-2
mutter: 42.0-2
mesa: 22.0.2-1
gtk4: 1:4.6.3-1
gtk3: 1:3.24.33-3
Processor: 11th Gen Intel(R) Core(TM) i7-1165G7
Graphics: Intel® Iris® Xe Graphics

Can you create a screencast of the issue?
See https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Collect_information_for_a_bug_report
Thanks.

(In reply to Martin Stránský [:stransky] (ni? me) from comment #7)

(In reply to matt.9.johnson from comment #6)

I wanted to add that I am still seeing this issue with firefox 100.0-1 on Archlinux. I also saw it on version 99.0.1. I am using gnome with wayland, and have enabled native wayland rendering in firefox with the MOZ_ENABLE_WAYLAND=1 environment variable. A possibly relevant detail is that my laptop has an odd sized screen, so I have enabled fractional scaling in wayland with the gnome settings key gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']", and use 150% scaling.

This is very easy for me to reproduce, so let me know if there are any tests I can run to help debug. For me, almost any overlay generated by the browser (incluiding hover text or dropdowns) gets "stuck". It seems to be stuck in the browser's buffer, not the system's, since I can switch applications and the menus disappear, but they are still there when I switch back to firefox, and still visible when switching tabs within firefox. I'm happy to provide screenshots if helpful too. I will switch to nightly and see if I have better luck.

environment is:
wayland: 1.20.0-2
mutter: 42.0-2
mesa: 22.0.2-1
gtk4: 1:4.6.3-1
gtk3: 1:3.24.33-3
Processor: 11th Gen Intel(R) Core(TM) i7-1165G7
Graphics: Intel® Iris® Xe Graphics

Can you create a screencast of the issue?
See https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Collect_information_for_a_bug_report
Thanks.

Hi Martin,
I'm new to the mozilla bug tracker and not sure how to directly attach the screencast. It's available here (google), but let me know if there is a way to upload directly. I tried to capture the behavior showing the overlays getting stuck in the current window, even when switching tabs or navigating to new sites, as well as them being isolated to the current window (they disappear when I switch to nightly or a different window of regular firefox). It seems like the url bar does not get stuck, nor does the right click menu, if that helps narrow things down? Clicking on the main hamburger menu, any alt-text overlays, and the privacy details menus do get stuck.

Separately, I installed firefox-nightly via the AUR in parallel, and have not seen the issue there. I think firefox nightly uses the built binary from mozilla directly, while the main firefox package is built in the archlinux toolchain from source with arch's latest versions of all the dependencies. Would it be helpful for me to build nightly from source in an arch latest environment and/or test a mozilla build of release 100?
-mj

I just uploaded a screencast as well.

Like @matt.9.johnson, I have Gnome's scale-monitor-framebuffer setting enabled. I tried disabling it but the issue still occured. However, running Firefox with MOZ_ENABLE_WAYLAND=0 environment variable fixes the issue.

In searching for details on how to upload the video, I found the general bug reporting guidelines which suggest trying to reproduce the issue in a new profile. With a clean profile in regular (not nightly) firefox 100.0-1 I don't encounter the issue immediately like I do with my regular installation and default profile. I'll try and bisect to see if there is an issue with a particular extension I have installed (I don't have many and they're all of relatively high reputation) or a particular setting. In the meantime I attached the about:support dumps from the working profile and broken profile (both in firefox 100.0-1), and uploaded my screencast directly to complement Julien's.

After bisecting, the issue appears to only appear with the modified config setting gfx.webrender.compositor.force-enabled: true. Reverting to the default gfx.webrender.compositor.force-enabled: false and then restarting firefox fixes the issue at hand for me. I had enabled this about 6 months ago as a recommendation for saving power on a laptop, but I guess this is why there's an about:config warning : ) I'm not sure of the code path this setting opens up on firefox 99+, but maybe this bug can be moved to a more specific component for whoever is responsible for that config item.

(In reply to matt.9.johnson from comment #15)

After bisecting, the issue appears to only appear with the modified config setting gfx.webrender.compositor.force-enabled: true. Reverting to the default gfx.webrender.compositor.force-enabled: false and then restarting firefox fixes the issue at hand for me.

That's interesting, Thanks.

Julien,
can you run it on terminal with

MOZ_LOG="WidgetPopup:5"

env variable set and attach the log here?
Thanks.

This was reported in bug 1752678.

Log attached.

I also have gfx.webrender.compositor.force-enabled set to true and setting it to false fixes the issue.