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

Steps to reproduce:

1. Make sure you are under Linux, Firefox 100 and Wayland/MOZ_ENABLE_WAYLAND=1.
2. Visit a website, such as mozilla.org
3. bookmark website via the star in the URL-bar
4. select a different location

This is just an example, a similarly looking issue occurs with for example the context menu, however is not reliably reproducible, hence I haven't figured out the exact circumstances yet.

Actual results:

The bookmark-popup vanishes and just the location-submenu stays visible (see attached image). When selecting something there, the star still shows as "pressed". Hitting escape makes it go empty again, hitting enter makes it stay blue, strongly implying that the popup window is still there and functioning, Return triggering setting the bookmark, escape triggering an abort/remove bookmark.

This behavior is reproducible with nightly, it occurs under sway 1.7, gtk3-version is 1:3.24.33-3. gtk3 is the same version that was installed .

Expected results:

The bookmark-popup should have stayed visible below the new menu.

Unfortunately I did not manage to bisect the code due to mach not finding my terminfo database, should this error sound easy to fix to you we could go down that route and see if I can get firefox to build to bisect for the problematic changeset.
(_curses.error: setupterm: could not find terminfo database).

If there are any other information I can provide to help just say so.

To be precise (as I can't seem to edit and want to rephrase to avoid confusion): I have a bootstrapped copy of Firefox, a pythn 3.7 for building, but mach doesn't proceed with the aforementioned error (including stacktrace) which prevents me from building Firefox unfortunately, hence I cannot bisect. But maybe we don't necessarily need this, if the bug is easy to find by any chance.

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.

You shouldn't need to build to bisect, you can run:

$  pip3 install --user mozregression
$ MOZ_ENABLE_WAYLAND=1 mozregression --good 96

(or so).

This seems to work for me in GNOME / Mutter, can you attach your about:support information?

Ok, mozregression is pretty damn awesome! :D

$ MOZ_ENABLE_WAYLAND=1 mozregression --good 99 --bad

[…]
6:48.82 INFO: No more integration revisions, bisection finished.
6:48.82 INFO: Last good revision: 1da49b17c30399c2c80886c322b7e6ac0469ef94
6:48.82 INFO: First bad revision: 8a83aa3ec30981da1a9affddb67339f55959e529
6:48.82 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=1da49b17c30399c2c80886c322b7e6ac0469ef94&tochange=8a83aa3ec30981da1a9affddb67339f55959e529

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

:stransky, since you are the author of the regressor, bug 1760276, could you take a look?
For more information, please visit auto_nag documentation.

Please report that to Sway bug tracker as it works in Gnome/KDE.
Thanks.

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

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

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

A needinfo is requested from the reporter, however, the reporter is inactive on Bugzilla. Closing the bug as incomplete.

For more information, please visit auto_nag documentation.

For the record: As far as I can tell this seems to be fixed by sway with (at least) current versions of sway (1.8) and/or firefox (108.0.2).

Could possibly be "RESOLVED -> FIXED", but I can't do that, so if upstream wants to have their bug tracker tidy in a particular way, please override. :)