Closed Bug 1820542 Opened 1 year ago Closed 4 months ago

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

Categories

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

Firefox 110
Unspecified
Linux
defect

Tracking

()

RESOLVED FIXED
122 Branch
Tracking Status
firefox-esr102 --- unaffected
firefox-esr115 --- wontfix
firefox111 + wontfix
firefox112 + wontfix
firefox113 + wontfix
firefox114 --- wontfix
firefox122 --- fixed

People

(Reporter: vincent-moz, Assigned: jld)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

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.

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

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.

Component: Untriaged → Menus

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

Flags: needinfo?(vincent-moz)

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).

Flags: needinfo?(vincent-moz)

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.

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

(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...

Component: Menus → Widget: Gtk
Flags: needinfo?(vincent-moz)
Product: Firefox → Core

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

Flags: needinfo?(vincent-moz)

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

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(vincent-moz)

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?

Flags: needinfo?(vincent-moz)

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

Flags: needinfo?(vincent-moz)

(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.

Flags: needinfo?(vincent-moz)

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?

Flags: needinfo?(vincent-moz)

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.

Flags: needinfo?(vincent-moz)

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

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

What about if you set XDG_CURRENT_DESKTOP=fvwm?

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

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

(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.

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.

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.

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.

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

Keywords: regression
OS: Unspecified → Linux
Regressed by: 1798131

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

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.

Flags: needinfo?(gpascutto)
Assignee: nobody → emilio
Flags: needinfo?(gpascutto)
Summary: Menu handling with the mouse is broken → Menu handling with the mouse is broken [FVWM/VTWM]
Priority: -- → P3

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.

Flags: needinfo?(stransky)

(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)

Flags: needinfo?(stransky)

(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).

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 (!!)

:emilio what are the next steps here?

Flags: needinfo?(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.

Flags: needinfo?(emilio)

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.

:jld what do you think regarding comment 32?

Flags: needinfo?(jld)

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.

Flags: needinfo?(jld)

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?

Flags: needinfo?(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}?

Flags: needinfo?(emilio)

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.

Flags: needinfo?(jld)

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

Assignee: emilio → jld
Flags: needinfo?(jld)
See Also: → 1750721

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).

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.

Pushed by jedavis@mozilla.com:
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
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 114 Branch

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.

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).

(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.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

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.

See Also: → 1831433

(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 ?

(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.

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.

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...

Flags: needinfo?(jld)

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.

Status: REOPENED → RESOLVED
Closed: 1 year ago4 months ago
Flags: needinfo?(jld)
Resolution: --- → FIXED
See Also: → 1864382

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.

Target Milestone: 114 Branch → 122 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: