GNOME Bugzilla – Bug 752327
second right-click on header bar buttons brings WM menu, and leaves desktop almost unusable
Last modified: 2021-07-05 13:51:39 UTC
There is a weird issue with nautilus and some of its headerbar buttons, for example, opening nautilus (brings users $HOME) and in the left part of the headerbar there are three buttons '<' '>' '[HOME]', right-clicking on the '[HOME]' buttons brings regular nautilus menu "Open in New Window", "Open in New Tab" and "Properties", if you right-click again it opens a WindowManager menu, and makes the system "stuck", you can click under under it, but you cannot close the WindowManager menu, to workaround this you can open the Overview and then use WindowManager menu to close Nautilus. nautilus-3.16.2-2.fc22.x86_64 gtk3-3.16.5-1.fc22.x86_64 mutter-3.16.3-1.fc22.x86_64 gnome-shell-3.16.3-1.fc22.x86_64
From my investigation, there's a few things going wrong here: - Popup menus like the ones in the pathbar buttons apparently get implicitly in the default window group, whereas popup menus from GtkMenuButton, or the </> buttons (which very much seem custom togglebuttons) get a different one. This is quite strange as I don't see any explicit gtk_window_group_add_window() calls being made, still investigating this. - The gtk_window_check_handle_wm_event() hack in gtkmain.c misbehaves precisely when a grab is being held in another toplevel from the same group, making it think it's ok to handle the event for drags/resizes/popups. - The "left unusable" part of the bug comes when mutter pops up the menu even though there's a grab elsewhere (and thus fails to take its own), so it is just left there unable to receive events. There should be probably checks on both gtk+ and mutter to prevent this from happening. Patches coming for #2 and #3 on the gtk+ side so far.
Created attachment 308736 [details] [review] gtkmain: Don't process WM events if there's a grab on another toplevel This is implicitly done for us in the case of grabs on windows from other groups, but we must perform this check explicitly for grabs with owner_events=True on windows from the same group, in that case the window would handle the events as if there was no grab.
Created attachment 308737 [details] [review] gtkwindow: bail out on WM operations in the presence of grabs These operations will require a grab on the WM side, so we can spare the attempt from the WM to take a grab when we're certain it won't suceed.
Review of attachment 308736 [details] [review]: ok
Review of attachment 308737 [details] [review]: makes sense. although not strictly necessary, right ?
(In reply to Matthias Clasen from comment #5) > Review of attachment 308737 [details] [review] [review]: > > makes sense. although not strictly necessary, right ? Right, the first patch suffices to make the reported bug go away (this one alone too fwiw), you could still conceivably fall into this code while keeping an X grab inside a child window of this toplevel, so might do as an extra safety net. The last one should be ultimately implemented in mutter though.
Attachment 308736 [details] pushed as a6ca569 - gtkmain: Don't process WM events if there's a grab on another toplevel Attachment 308737 [details] pushed as 69c9cb8 - gtkwindow: bail out on WM operations in the presence of grabs
Moving this to mutter for the last part, then.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/mutter/-/issues/ Thank you for your understanding and your help.