1876012 - Tab dragging opens the menu if the mouse pointer goes over "Bookmarks" in the menu bar, and locks the GUI when widget.gtk.grab-pointer = 1

Status: NEW

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

Description

[Vincent Lefevre]

Attachment: photo.jpg

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

Steps to reproduce:

Preliminary: Make the menu bar visible if not already done.

1. Start to drag a tab.
2. While dragging, put the mouse pointer over "Bookmarks" in the menu bar.
3. Release the mouse button.

Actual results:

After step 2, the Bookmarks menu appears. Then Firefox still thinks that dragging is ongoing: the mouse pointer is still the hand with an arrow. But I cannot do anything, except moving the mouse pointer (clicking doesn't have any effect). The UI doesn't react, and I can't have access to the other applications. The display in the other applications can still be updated (e.g. the clock). I can switch to another VT with the keyboard and go back, but the situation remains the same. I need to log in remotely by SSH and kill Firefox (I suppose that I could also do that from a VT, but without the ability to see the effect immediately on the screen).

I've attached a photo showing the Bookmarks menu and the mouse pointer.

Expected results:

The Bookmarks menu shouldn't appear while dragging. And dragging should have stopped.

Possibly related to bug 1821837 I had several months ago. But with the above steps, this is 100% reproducible, and clicking doesn't have any effect, making the problem much worse.

Comment 1

[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 2

[Vincent Lefevre]

Additional detail: I use the FVWM window manager, and the GUI lock occurs only with widget.gtk.grab-pointer = 1 or 2 (2 is equivalent to 1 with FVWM). With widget.gtk.grab-pointer = 0, the opening of the Bookmarks menu still incorrectly occurs, but this doesn't have major consequences. Note that in any case, the other menus do not open; this is specific to the Bookmarks menu.

When the GUI lock occurs, typing the Ctrl key unblocks the situation.

Comment 3

[Vincent Lefevre]

This bug is still present in Firefox 122.0.

Comment 4

[Hani Yacoub, Desktop QA]

Managed to reproduce this bug on Ubuntu 20.04 x64.
The issue is not reproducible on Windows 10 x64 or on macOS 11.6.

Comment 5

[Mike Conley (:mconley) (:⚙️)]

A workaround for this is to press "Escape" to end the drag operation, which should put the browser back into an interactive state.

Hey Marco, I presume it's expected that we open the Bookmarks menu when dragging a tab, right? Presumably, we need to be ending the drag session if the user hasn't finished the drag properly... do you know whereabouts in the codebase we'd need to do that?

Comment 6

[Marco Bonardo [:mak]]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #5)

A workaround for this is to press "Escape" to end the drag operation, which should put the browser back into an interactive state.

Hey Marco, I presume it's expected that we open the Bookmarks menu when dragging a tab, right? Presumably, we need to be ending the drag session if the user hasn't finished the drag properly... do you know whereabouts in the codebase we'd need to do that?

Yes, it's expected that we open certain menus when the user is hovering them, and once the operation is complete the menu should stay open to show the newly inserted item, the menu should also close on a timer if the user drags out of it.
On Windows everything works exactly like that, just tested it.
And according to comment 2 it also works correctly with widget.gtk.grab-pointer = 0.

I think the problem here is in the DnD code that handles the drag session and how it interacts with FVWM and widget.gtk.grab-pointer.