1820542 - Menu handling with the mouse is broken [FVWM/VTWM]

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect, P3)

Description

[Vincent Lefevre]

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

Steps to reproduce:

1. Start Firefox, configured with the menu bar enabled.
2. Click on "File".
3. Move the mouse pointer to the right (over "Edit").

Actual results:

The "Edit" menu sometimes appears, sometimes it doesn't. When it appears, its first item ("Undo") is sometimes automatically selected, sometimes it isn't. Similar issue with the other menus (History, Bookmarks...). The behavior appears to be random.

Another test: If I click on "Bookmarks", its menu appears. Then if I move the mouse pointer to "Tools", its menu sometimes appears, but not always. When it appears, if I move the mouse pointer backward to "Bookmarks", the "Tools" menu is still shown and its first item ("Downloads") gets selected, even though the mouse pointer is over "Bookmarks".

The handling of the context menu over this textarea is also broken when I make the "Languages" submenu appear: the position of the cursor over its items ("English" and all the "French" variants) changes when I move the mouse while the mouse pointer is actually over the first items of the context menu ("Undo", "Redo", "Cut", "Copy"...).

Note that if I try to navigate in the menu items with the keyboard arrow keys, this seems to be OK (whether I try with the menu bar or with the context menu). So the problem seems to be with the mouse tracking.

Expected results:

The menus should work in the usual way.

Comment 1

[Vincent Lefevre]

Note that there is the same issue with a new profile (at least with the menu bar, just after enabling it).

Comment 2

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

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

Comment 3

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

Hi, I noticed you're using linux. What distro and window manager are you using?

Comment 4

[Vincent Lefevre]

Debian/unstable, with its firefox 110.0.1-1 package. My window manager is FVWM.

This issue occurs both on my desktop machine at my lab and my laptop machine at home. It is new, so I think that it appears with FF 110 (on both machines).

Comment 5

[Vincent Lefevre]

I confirm that the bug appeared with FF 110: I've tried the firefox 109.0-1 Debian package on my laptop, and the bug does not occur with it. And the bug reappeared with the upgrade to the firefox 110.0.1-1 package.

Comment 6

[reikred]

I have the same problem with ubuntu 22.04.1 and X11/vtwm window manager. When you click on a menu (any menu, for example FIle or the stackmenu or mouse context menu), the menu is supposed to stay open while you move the mouse to the item you want to select. Instead the menu disappears as soon as the mouse is moved.

Problem observed in 110.0.1, and was not observed in 103.2

Comment 7

[:Gijs (he/him)]

(In reply to Vincent Lefevre from comment #5)

I confirm that the bug appeared with FF 110: I've tried the firefox 109.0-1 Debian package on my laptop, and the bug does not occur with it. And the bug reappeared with the upgrade to the firefox 110.0.1-1 package.

Can you try using mozregression to narrow down what regressed this to a single commit? I think without being able to reproduce this it'll be hard to know exactly what's wrong otherwise.

Moving to GTK land as it seems pretty clear this is an X11/wayland/gtk-framework integration issue rather than something frontend has done. Copying in Emilio as he's done some recent work on menu frame stuff so he might have clues...

Comment 8

[Vincent Lefevre]

I've tried mozregression in a firejail private directory (so the results are not affected by my config). But note that there are broken versions that show a different behavior: menus disappear when they shouldn't, but this appears to be a bit less broken than in my bug report. So...

20221206173957 is good
20221207041118 is bad

Then mozregression tested 20221206204650, which crashes: Process exited with code 11. But this may be unrelated to this bug. So I'm not sure what to do now.

The summary:

14:00.01 INFO: Newest known good integration revision: ad6a4e59525c845b8d71b65c3471efc41a3aa7a1
14:00.01 INFO: Oldest known bad integration revision: 99052dd249cc79a752aeed699b8cb4633f3d2cd9
14:00.01 INFO: To resume, run:
14:00.01 INFO: /home/vlefevre/bin/mozregression --repo=autoland --good=ad6a4e59525c845b8d71b65c3471efc41a3aa7a1 --bad=99052dd249cc79a752aeed699b8cb4633f3d2cd9

Comment 9

[Emilio Cobos Álvarez (:emilio)]

That push range contains bug 1798131. This looks a lot like bug 1805939 / bug 1807482. A workaround for FVWM landed in bug 1814291, but that only made it to the 111 branch unfortunately :(

vtwm is one I hadn't heard of. Probably needs a similar workaround as twm here

Comment 10

[Vincent Lefevre]

Well, using "skip" allowed my to go further.

20221206223244 is good
20221206225723 is bad

7:44.23 INFO: No more integration revisions, bisection finished.
7:44.23 INFO: Last good revision: 850c9756f206a4e29a7b2720fad6c918ffda33df
7:44.23 INFO: First bad revision: 9b1c242dc2e0dce955e83320a28227c9817d9d57
7:44.23 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=850c9756f206a4e29a7b2720fad6c918ffda33df&tochange=9b1c242dc2e0dce955e83320a28227c9817d9d57

Do you confirm that's the bugs you mentioned?

Comment 11

[Emilio Cobos Álvarez (:emilio)]

Yes, can you check that 111 beta works for you in fvwm?

Comment 12

[Vincent Lefevre]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #11)

Yes, can you check that 111 beta works for you in fvwm?

Not tried, but note that Nightly is still buggy. Or is that a patch that is in the 111 branch but not in the main branch?

Moreover, bug 1814291 says in the tracking flags: "firefox110 --- fixed". I'm confused.

Comment 13

[Emilio Cobos Álvarez (:emilio)]

Oh, no, Nightly also has that patch... What does about:support say about your desktop environment, do we find out that you're running fvwm?

Comment 14

[Vincent Lefevre]

I've tried Nightly and 111.0b8, and both behave in the same way and are much more broken than when the bug started to appear (see Comment 8).

about:support says that the desktop environment is fvwm.

In case this matters, I have the following in my FVWM config about focus issues:

# Disable focus stealing and so on. This is particularly annoying when
# the window is on another desktop. With Firefox, the following solves
# the focus problem, but the window is still de-iconified and raised.
# More information about this Firefox problem:
#   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478981
#   https://bugzilla.mozilla.org/show_bug.cgi?id=263553
# See also:
#   http://fvwmforums.org/wiki/Tips/FocusStealing/
DestroyFunc EWMHActivateWindowFunc
AddToFunc EWMHActivateWindowFunc I Nop

As you can see, this is about a 19-year old issue (bug 263553), but which was closed as WONTFIX (though bug 775400, about the same issue IIRC, is still open). However, if I comment out these 2 lines, restart FVWM and run Nightly again, the menu issue still occurs.

Comment 15

[Vincent Lefevre]

The menu issue also occurs with Nightly and the default FVWM config under Debian.

Comment 16

[Vincent Lefevre]

Hmm... With FF 110, about:support says fvwm, but not with Nightly. The reason may be that I test Nightly in a private directory, so that it doesn't have the usual environment. But even if I set up the FVWM-related envrionment variables in the private directory, about:support still says nothing.

$ env | grep FVWM
FVWM_USERDIR=/home/vlefevre/.fvwm
FVWM_DATADIR=/usr/share/fvwm2
FVWM_MODULEDIR=/usr/libexec/fvwm2/2.7.0

Comment 17

[Emilio Cobos Álvarez (:emilio)]

What about if you set XDG_CURRENT_DESKTOP=fvwm?

Comment 18

[Emilio Cobos Álvarez (:emilio)]

I just tried (on Arch, not Debian) and for some reason sddm sets XDG_CURRENT_DESKTOP= (empty string), which breaks our detection.

Comment 19

[Vincent Lefevre]

First, the issue with the environment variables is unrelated: with FF 110 (Debian's package) in a private directory, about:support says fvwm. So I do not understand the difference with Nightly.

Setting XDG_CURRENT_DESKTOP=fvwm does not solve the issue and breaks the FVWM window decorations. Note that XDG_CURRENT_DESKTOP is unset by default.

FYI:

cventin:~> env | grep XDG_
XDG_SEAT=seat0
XDG_SESSION_TYPE=x11
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
XDG_SESSION_CLASS=user
XDG_SESSION_ID=972
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session6
XDG_RUNTIME_DIR=/run/user/1000
XDG_SESSION_DESKTOP=lightdm-xsession
XDG_GREETER_DATA_DIR=/var/lib/lightdm/data/vlefevre
XDG_VTNR=7

Comment 20

[Vincent Lefevre]

(In reply to Vincent Lefevre from comment #19)

Setting XDG_CURRENT_DESKTOP=fvwm does not solve the issue and breaks the FVWM window decorations.

More precisely, the menu handling is still broken and about:support does not say anything about the desktop environment.

Comment 21

[Emilio Cobos Álvarez (:emilio)]

Yep, I noticed about:support doesn't display the DE on Nightly, fix in bug 1822315. The side effect of removing decorations is expected I believe.

I don't see the broken menu handling here tho. This is with fvwm 2.6.9-3 on Arch with a pristine setup.

Comment 22

[Emilio Cobos Álvarez (:emilio)]

Oh, I lie, I could repro.

Can you confirm that setting widget.gtk.grab-pointer = 0 the File-to-edit menu transition / hover over the menubar works as you expect? You should see menus closing as you leave the popup tho.

Comment 23

[Vincent Lefevre]

The one-year old version 2022-03-14 in the mozregression test does not say anything about the desktop environment either (but this was a Nightly at that time, if I understand correctly).

Note that the menu is also broken with Nightly when I use twm instead of fvwm.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #22)

Can you confirm that setting widget.gtk.grab-pointer = 0 the File-to-edit menu transition / hover over the menubar works as you expect? You should see menus closing as you leave the popup tho.

Yes, this is the "less broken" behavior I mentioned in Comment 8.

Comment 24

[Sylvestre Ledru [:Sylvestre]]

[Tracking Requested - why for this release]:
Recent regression on linux

Comment 25

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

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

Comment 26

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

The bug is marked as tracked for firefox111 (release). However, the bug still isn't assigned.

:gcp, could you please find an assignee for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit auto_nag documentation.

Comment 27

[reikred]

Please include also plain "twm" in the list of window managers or "desktop environments" that should be detected for the bugfix. There may also be others.

Is the fix via environment variable now? Or via some internal browser setting in about:config? I ask because I saw somewhere a suggested fix that looked roughly like

if (windommanger == "vtwm") then
...

Having something that is less hard-coded and more programmable is crucial given that there may very well be more cases of window managers that need the fix. Sorry, I'm not able to find the relevant code snippet, it just flew by somewhere. Thx.

Comment 28

[Emilio Cobos Álvarez (:emilio)]

(In reply to reikred from comment #27)

Please include also plain "twm" in the list of window managers or "desktop environments" that should be detected for the bugfix. There may also be others.

twm is already in the list of WMs here. But twm doesn't implement the extensions that allow us to query the name, so it won't work automatically unless you have something like XDG_SESSION_DESKTOP=twm or so.

In any case it's very intentionally not hard-coded. There are prefs to override this. e.g., widget.gkt.grab-pointer=1 in about:config (read here)

Comment 29

[Vincent Lefevre]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #28)

In any case it's very intentionally not hard-coded. There are prefs to override this. e.g., widget.gkt.grab-pointer=1 in about:config (read here)

Without the typo: widget.gtk.grab-pointer (you should do copy-paste to avoid typos).

But note that currently, none of the values work with FVWM (I've tried, 0, 1 and 2).

Comment 30

[reikred]

Thanks to :emilio and Vincent Lefevre for informative clarification and link to the relevant code. Very useful for documenting and understanding how the fix is going to work.

Note to self: nsWindow.cpp (!!)

Comment 31

[Suhaib Mujahid [:suhaib]]

:emilio what are the next steps here?

Comment 32

[Emilio Cobos Álvarez (:emilio)]

So this got a bit confusing. As I understand, comment 0 in FVWM is (at least partially) caused by bug 1814291. I don't have a strong opinion on whether we should undo that or not (ni?ing Jed for context).

TWM/VTWM is not possible to workaround on our end because it doesn't implement the required WM extensions, but if you provide an env variable to allow detecting it we can do that.

Other than that, this affects a tiny fraction of our Linux users (those using somewhat exotic/old non-compositing WMs), so I don't think it's worth spending a lot of extra time on it.

Comment 33

[Vincent Lefevre]

This is a very annoying issue for FVWM users. How about re-enabling the old code (until a better fix would be found), which would be available by setting widget.gtk.grab-pointer to some value? FVWM was not affected by bug 1798131.

Note that Firefox is the only application with such an issue. All the other applications work fine with FVWM.

Comment 34

[Suhaib Mujahid [:suhaib]]

:jld what do you think regarding comment 32?

Comment 35

[Jed Davis [:jld] (on leave until 08-31)]

I can reproduce this with FVWM, and it seems related to something I'd noticed: in a context menu, mousing over an item with a submenu seems to (sometimes?) grab the mouse for the submenu even though the pointer is still in the parent menu, and it will highlight items in the submenu based on where the pointer is relative to the upper left of the parent menu. So I'm wondering if this is maybe just a problem with coordinate conversion or otherwise getting windows mixed up, and possibly fixable without too much work.

Turning off widget.gtk.grab-pointer does fix that, but of course brings back the problem with menus immediately being dismissed when the pointer leaves them.

Comment 36

[Jed Davis [:jld] (on leave until 08-31)]

Emilio: I hate to keep bothering you about weird X11 focus things, but, does the description in comment #35 sound like anything? Is there someplace obvious in the code that's doing the pointer grabs where we might be using the wrong window's coordinates?

Comment 37

[Emilio Cobos Álvarez (:emilio)]

Not really, this is the only relevant code afaict... I guess GetTopLevelGtkWindow could return something wrong perhaps? Or gtk is doing something suspicious on gtk_grab_{add,remove}?

Comment 38

[Jed Davis [:jld] (on leave until 08-31)]

I found something while looking around the code / revision history: This appears to be a repeat of bug https://bugzilla.mozilla.org/show_bug.cgi?id=1750721. The screen recording in that bug looks exactly like what I described in comment #35.

I'll see if making the same change (from gdk_device_grab to gdk_pointer_grab) to the current state of the tree fixes this.

Comment 39

[Jed Davis [:jld] (on leave until 08-31)]

It seems to work. I'll send a patch.

Comment 40

[Jed Davis [:jld] (on leave until 08-31)]

Attachment: Bug 1820542 - Use gdk_pointer_grab instead of gdk_device_grab to avoid bug with nested menus.

This is the same issue as bug 1750721, where we react to the pointer
position relative to the wrong window when the pointer is grabbed for a
popup menu. It was reintroduced in the cluster of bugs that removed and
partly readded our use of pointer grabbing (bug 1807482 in particular).

Comment 41

[Jed Davis [:jld] (on leave until 08-31)]

For reference, this bug can even be reproduced in GNOME on stock Ubuntu, by setting MOZ_ENABLE_WAYLAND=0 in the environment so it uses XWayland, setting the widget.gtk.grab-pointer pref to 1, and mousing through the context menu for a tab.

Comment 42

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d262b19825bf
Use gdk_pointer_grab instead of gdk_device_grab to avoid bug with nested menus. r=emilio

Comment 43

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/d262b19825bf

Comment 44

[Vincent Lefevre]

Thanks. I don't know whether this is supposed to be fixed in Nightly 114.0a1 (2023-05-04), but while there is no longer any issue with submenus (whether widget.gtk.grab-pointer is set to 1 or 2), the menu bar is still broken: when I open some menu and move the mouse pointer to other ones in the menu bar (e.g. from "Bookmarks" to "Tools"), at some moment, the menu automatically closes; I need to click again. This seems completely random.

Comment 45

[Vincent Lefevre]

Note: with widget.gtk.grab-pointer set to 0, there are no issues with the menu bar as long as the mouse pointer remains over it (otherwise, with this value, there's the menu disappearing as described in the previous comments).

Comment 46

[Jed Davis [:jld] (on leave until 08-31)]

(In reply to Vincent Lefevre from comment #44)

Thanks. I don't know whether this is supposed to be fixed in Nightly 114.0a1 (2023-05-04), but while there is no longer any issue with submenus (whether widget.gtk.grab-pointer is set to 1 or 2), the menu bar is still broken: when I open some menu and move the mouse pointer to other ones in the menu bar (e.g. from "Bookmarks" to "Tools"), at some moment, the menu automatically closes; I need to click again. This seems completely random.

I can confirm this (and comment #45 about turning off mouse grab). My apologies; I assumed the two versions of the bug were the same underlying issue and forgot to check.

Comment 47

[cervino]

Thanks for reporting / working on this bug! I am using openSUSE 15.4 / fvwm 2.6.9 (focus does not follow pointer) / Firefox 112.0.2. Navigating through my bookmark hierarchy was painful during the last few months. Setting widget.gtk.grab-pointer to 0 re-established the usual behavior of the Firefox menus.

Comment 48

[reikred]

(In reply to cervino from comment #47)

Thanks for reporting / working on this bug! I am using openSUSE 15.4 / fvwm 2.6.9 (focus does not follow pointer) / Firefox 112.0.2. Navigating through my bookmark hierarchy was painful during the last few months. Setting widget.gtk.grab-pointer to 0 re-established the usual behavior of the Firefox menus.

Hmm, that is not what works for me with vtwm. For me, using ubuntu and vtwm, setting widget.gtk.grab-pointer = 1 (not 0 , not 2) is what is needed for menus not to close/disappear upon mouse1.release + mouse1.movement.

I just upgraded firefox from 109.0.1 to 118.0.2. For version 118.0.2, the bug is still there with vtwm when widget.gtk.grab-pointer = 0 or 2. In comment 43 and 46 it is indicated that there was a fix in 114.0a1. How is the fix then seemingly not in 118.0.2 ?

Comment 49

[Vincent Lefevre]

(In reply to Vincent Lefevre from comment #44)

Thanks. I don't know whether this is supposed to be fixed in Nightly 114.0a1 (2023-05-04), but while there is no longer any issue with submenus (whether widget.gtk.grab-pointer is set to 1 or 2), the menu bar is still broken: when I open some menu and move the mouse pointer to other ones in the menu bar (e.g. from "Bookmarks" to "Tools"), at some moment, the menu automatically closes; I need to click again. This seems completely random.

With Firefox 122.0, I no longer have this issue (widget.gtk.grab-pointer is set to 2 and the window manager is FVWM). But the problem may have disappeared in earlier versions.

Comment 50

[Vincent Lefevre]

I've just tested Firefox 121.0.1 (firefox 121.0.1-1 Debian package) with a new profile, and the menu handling was broken. After upgrading to Firefox 122.0 (firefox 122.0-1 Debian package) and testing with the same profile, the menu handling is correct. So it seems that the bug was eventually fixed in Firefox 122.

Comment 51

[:Gijs (he/him)]

Jed, can we close this out as per Vincent's last few comments? I confess to being a bit lost about the various problems (and settings + window management combinations) here. It would be somewhat interesting to find out where/when this got fixed if it's easy to find out...

Comment 52

[Jed Davis [:jld] (on leave until 08-31)]

It does appear to be fixed for FVWM, using the STR from comment #44. I spent a few minutes with mozregression and narrowed it down to this range of commits, and bug 1864382 looks relevant.

The case of vtwm mentioned in comment #48: I think that's just because we don't detect it, so widget.gtk.grab-pointer has to be turned on manually (2 = auto-detection). As comment #32 mentioned, twm doesn't announce itself in root window properties the way newer window managers do, but if an environment variable has been set by a display manager (basically if env | grep -i twm mentions something relevant) then there may be something that could be added to this code.

Comment 53

[Vincent Lefevre]

Note that if the mouse moves very quickly over the menu items of the menu bar, the popups disappear; I need to click again on a menu item to get them back. However, this seems to be a different bug (unless this is done on purpose), as this does not depend on the widget.gtk.grab-pointer value (contrary to all the other issues), and I can see that the very old Firefox 52.9.0 (I still have a copy on this machine) already had this issue.