GNOME Bugzilla – Bug 748892
wayland: focus issue with gnome-terminal
Last modified: 2015-06-24 14:49:04 UTC
Summary: Focus-follow-mouse in mutter under wayland seems broken. Steps to reproduce: 1. Open gnome-terminal 2. From that terminal, open another terminal (File -> Open terminal) 3. Try to focus that other terminal and tart typing Expected result: Input focus is where it's shown. Actual result: The focused window looks like it's focused, the cursor blinks as expected, yet all input will still go to the other unfocused terminal - That's very confusing and even embarrassing when that other terminal is running irrsi! :) Additional information: Open a menu in the window and cancel with Escape and the focus is correctly set.
btw, the same issue occurs in click-to-focus (default) mode as well, so it's not related to the focus mode.
Actually, on further investigation, it seems that mutter sets the focus to the surface as expected, so I suspect this is actually a bug with gnome-terminal instead. Beside, the exact same issue arise with Weston as well, so it would rule out mutter as the problem.
(In reply to Olivier Fourdan from comment #0) > The focused window looks like it's focused, the cursor blinks as expected, > yet all input will still go to the other unfocused terminal That means that gtk+ is still delivering the input events to the 'unfocused' window. Nothing that g-t/vte can do. -> gtk+
One more observation: * Using the menu to open a new terminal -> focus is wrong * Using the keyboard shortcut (Ctrl-Shift-n) to do the same -> focus is as expected So it looks like the use of a menu is playing a role in the problem (also when focus is stuck, opening a menu and closing it will restore the focus where expected, comment #0)
Yet I fail to come up with a simple reproducer using gtk+ alone, not I can find any other app that exhibit the same behaviour so maybe it's g-t triggering that bug in gtk but I still don't know how... Using GDK_DEBUG on gnome-terminal-server, I can see the following: 1. Open the first window | Gdk-Message: focus in, device 0xed0190 surface 0x1364150 First message, surface 0x1364150 is the first window, focus is as expected. 2. Open the menu, File -> Open Terminal -> Default A few focus-in/focus-out events occur (expected, because of multiple menus): | Gdk-Message: focus out, device 0xed0190 surface (nil) | Gdk-Message: focus in, device 0xed0190 surface 0x13c57e0 | Gdk-Message: focus out, device 0xed0190 surface (nil) | Gdk-Message: focus in, device 0xed0190 surface 0x1472540 | Gdk-Message: focus in, device 0xed0190 surface 0x1364150 | Gdk-Message: focus out, device 0xed0190 surface (nil) | Gdk-Message: focus in, device 0xed0190 surface 0x15ef2a0 3. At this point here, the new terminal is now opened and mapped, looks like it has focus, the logs seem to correlate that observation (now "focus in surface 0x15ef2a0", original surface was 0x1364150) Yet when typing, it still goes to the original window/surface. 4. Open a menu in the (new) second window, and just discard the menu: | Gdk-Message: focus out, device 0xed0190 surface (nil) | Gdk-Message: focus in, device 0xed0190 surface 0x1604bd0 | Gdk-Message: focus in, device 0xed0190 surface 0x15ef2a0 Now, focus-in is again on the surface 0x15ef2a0 but this time it works... typing goes to the right (second) window being focused. So it looks like gdkwindow-wayland is updating the surface as expected, yet keys do not go to the correct window the first time.
(In reply to Olivier Fourdan from comment #5) > Yet I fail to come up with a simple reproducer using gtk+ alone, not I can > find any other app that exhibit the same behaviour so maybe it's g-t > triggering that bug in gtk but I still don't know how... > [...] OK, some progress, gdb FTW. What confuses gtk+ is the use of a GtkWindowGroup. Basically what happens is that g-t creates a GtkWindowGroup for its windows and when opening a new terminal using the menu, the grab is on the menu so that gtk_main_do_event() will pick the GtkMenuBar attached to the current window and not the new window. Not using a GtkWindowGroup in g-t fixes the focus issue. I wonder why this affects Wayland and not x11 though.
Created attachment 304065 [details] Simple reproducer with gtk+ alone Simple reproducer using gtk+ alone demonstrating the issue. Build with: gcc menu.c -o menu -Wall -DWINDOW_GROUP=1 `pkg-config gtk+-3.0 --cflags --libs` No avoid the bug, use -DWINDOW_GROUP=0 instead.
Great detective work so far, Olivier!
I have not given up on this one (it's just that it's incredibly time consuming), but good news I think I have nailed it, will post a patch shortly!
Created attachment 305460 [details] [review] Proposed fix Do not rewrite events for Wayland
(In reply to Olivier Fourdan from comment #10) > Created attachment 305460 [details] [review] [review] > Proposed fix > > Do not rewrite events for Wayland Thanks so much for the investigation Olivier! I however think this patch is targetting the symptom, and not the real bug... gdk_device_grab_info() seems to be returning stale info from a previous grab (implicit or active). To me it seems the bug is somewhere in GtkMenu or the GDK wayland backend that doesn't trigger the removal of that grab. I've set a breakpoint in _gdk_display_end_device_grab(), and it seemed to confirm my suspicions, as soon as you click on a menu, I would expect that function called with implicit=true, in order to break the implicit grab, it however isn't. This rather looks to me like something the wayland gdk backend should be triggering upon showing an xdg_popup.
I doubt this is specific to GtkMenu tbh, maybe gdk-wayland backend. It seems to me that the grabs get released when a "grab-notify" signal is emitted from _gtk_widget_grab_notify() called by gtk_grab_notify()/gtk_grab_notify_foreach() in gtk/gtkmain.c In the case of a GtkMenu with a window-group, that signal is not emitted for the GtkMenu because of the portion of code the patch removes when using Wayland (I do have a branch with tons of logs added that tend to show this, I can share the -ugly- patch and/or logs if needed) I think we do not see this in x11 simply because the grab gets released automatically by the X server when the window menu is unmapped but Wayland has no grab per se (yet) so this is all managed by signals in gtk. Or am I mistaken?
(In reply to Olivier Fourdan from comment #12) > I doubt this is specific to GtkMenu tbh, maybe gdk-wayland backend. Yeah, my suspicion involving GtkMenu also involved GDK getting it into a confused state (eg. not sending GdkEventGrabBroken properly or somesuch) > > It seems to me that the grabs get released when a "grab-notify" signal is > emitted from _gtk_widget_grab_notify() called by > gtk_grab_notify()/gtk_grab_notify_foreach() in gtk/gtkmain.c I'm talking about GDK grabs, although those usually go hand in hand with GTK+ ones. > > In the case of a GtkMenu with a window-group, that signal is not emitted for > the GtkMenu because of the portion of code the patch removes when using > Wayland (I do have a branch with tons of logs added that tend to show this, > I can share the -ugly- patch and/or logs if needed) > > I think we do not see this in x11 simply because the grab gets released > automatically by the X server when the window menu is unmapped but Wayland > has no grab per se (yet) so this is all managed by signals in gtk. > > Or am I mistaken? Yes, right. X11 defines how do grabs interact, and the grab mechanism in GDK is largely based on it (in order to cater for client-side windows). On other backends we must emulate a similar behavior out of the platform specific semantics.
Created attachment 306002 [details] [review] wayland: Update grab serial when ungrabbing keyboards This was being done so only on pointers. Internally, a GdkDeviceGrabInfo is kept for each of the master pointer/keyboard, failing to do this for keyboards results in a stuck keyboard grab.
Tested, looks good to me! Thanks!
Attachment 306002 [details] pushed as de260ae - wayland: Update grab serial when ungrabbing keyboards