GNOME Bugzilla – Bug 776232
[wayland] second click goes to previously right clicked item in titlebar
Last modified: 2018-05-02 17:52:09 UTC
Created attachment 342156 [details] gtk click after right click (video) The left click on a widget in titlebar goes to previously right clicked widget on the titlebar (if any). I can reproduce this only with physical mouse, not with touchpad. Please see the attached screencast.
Can you please give the detailed steps on how to reproduce, as I cannot reproduce here, right click being mapped to window menu.
(In reply to Olivier Fourdan from comment #1) > Can you please give the detailed steps on how to reproduce, as I cannot > reproduce here, right click being mapped to window menu. OK. Here is how to reproduce: 1. Open gedit -> Right click in open button This shall open the window menu. 2. Now dismiss that by pressing escape, or clicking (right/left) on open button again. 3. Now left click on save button Result: The open button popdown is shown instead of the action of save button.
I wonder if it might be a mutter issue, seems we don't get the button release in the case of the window menu.
Looking at the gtk/gdk side of things, it appears that the "wrong" widget is selected in gtkmain's gtk_get_event_widget() based on the event given window, which is "kept" from the initial button press event's pointer_info.focus. Maybe mutter should send the client a leave notify on the surface when mapping the window menu? It would in the case of a "grab", but for the window menu there is no pointer grab issued, which is expected, but that might explain that side effect in gtk/gdk. x11 is not affected because the menu always trigger a pointer grab, afaik.
Still digging... When the window menu is mapped, the client gets a pointer leave notify (which is correct, as the menu will show up), and when the menu is dismissed, it gets an enter notify again. But then, get_event_window() in gdkwindow.c returns the original button window, not the actual gdk window, which is what is causing the issue, because gtk will pick the wrong widget (the GtkButton) based on that wrong gdk window.
The initial button 3 press which triggers the window menu will add a grab (in proxy_button_event() from gdkwindow.c) and because we don't get a button release, the grab remains in effect until another press/release occurs, which triggers the original button.
Created attachment 343164 [details] [review] [PATCH] wayland: release implicit grab when showing window menu That patch seems to fix the issue. -- An implicit grab is set when pressing a button, but when that button press triggers the xdg-shell show_window_menu, the client never gets the button release, and the grab remains active, causing the wrong widget to be triggered when another button press/release is issued. To avoid this, force a release of the grab when issuing a show_window_menu so that the next button click works as expected.
FWIW, I had this protocol patch to further define the behavior on compositor grabs: https://lists.freedesktop.org/archives/wayland-devel/2016-November/031884.html Which, except for wl_touch, is just additional documentation. Your patch looks correct and is not too different from what's being done in other places, but maybe we should go ahead and try to break implicit grabs on wl_pointer.leave?
(In reply to Carlos Garnacho from comment #8) > FWIW, I had this protocol patch to further define the behavior on compositor > grabs: > https://lists.freedesktop.org/archives/wayland-devel/2016-November/031884. > html Yes, that would clarify the behavior, but also requires a change in the compositor. > Which, except for wl_touch, is just additional documentation. Your patch > looks correct and is not too different from what's being done in other > places, but maybe we should go ahead and try to break implicit grabs on > wl_pointer.leave? Thing is, the issue seems to be pretty much specific to the case of the window menu, because the window menu is mapped by gnome-shell, thus a different client to the one that initiated the action. So I am not sure we really need to break implicit grabs on pointer leave in all cases, at least it works for most cases but the (external) window menu afaics. The patch would be at least an intermediary fix without risk of breaking much else (as limited to the window menu invocation) at least until a wider consensus is found (and implemented in the clients/compositors) - Trigering the wrong action is quite unexpected for the user, even is very limited to the use of header bar and window menu :)
(In reply to Olivier Fourdan from comment #9) > (In reply to Carlos Garnacho from comment #8) > > FWIW, I had this protocol patch to further define the behavior on compositor > > grabs: > > https://lists.freedesktop.org/archives/wayland-devel/2016-November/031884. > > html > > Yes, that would clarify the behavior, but also requires a change in the > compositor. Right, that could be. > > > Which, except for wl_touch, is just additional documentation. Your patch > > looks correct and is not too different from what's being done in other > > places, but maybe we should go ahead and try to break implicit grabs on > > wl_pointer.leave? > > Thing is, the issue seems to be pretty much specific to the case of the > window menu, because the window menu is mapped by gnome-shell, thus a > different client to the one that initiated the action. This is one of the cases observed there :) (or at least I intended to). The idea is that it doesn't really matter why a client will stop receiving pointer events, it would be *always* notified through wl_pointer.leave, despite the existence of grabs, or the current button(s) state. So, with this in mind, all of move/resize/show_window_menu requests should immediately trigger a wl_pointer.leave, as the compositor took over control of the pointer. Currently there's no such guarantees, so the client doesn't really know if the request was honored (eg. has a right serial) or not, until maybe the next enter/motion/button event. > > So I am not sure we really need to break implicit grabs on pointer leave in > all cases, at least it works for most cases but the (external) window menu > afaics. TBH I can't see why :), on the compositor side the implicit grab on the surface actor is broken to all effects, it's just the client which isn't notified. > > The patch would be at least an intermediary fix without risk of breaking > much else (as limited to the window menu invocation) at least until a wider > consensus is found (and implemented in the clients/compositors) - Trigering > the wrong action is quite unexpected for the user, even is very limited to > the use of header bar and window menu :) Sure, as said I see nothing wrong with the patch, just that I would like these "grab transfer" situations to be more consistent.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/721.