GNOME Bugzilla – Bug 755927
Occasional "stuck key" after closing window using keyboard shortcut in focus-follows-mouse mode
Last modified: 2015-10-07 04:30:01 UTC
I am running (self-compiled) Gnome 3.18 for a some time with the Wayland session (which works pretty well I must say) and observed an annoying issue: I am using the focus-follows-mouse mode (dconf key: "org.gnome.desktop.wm.focus-mode" = "mouse") and when I do e.g. the following: Two gnome-terminal windows on the naked desktop which do not overlap. Move mouse onto first window and close it using Ctrl-D. When I then move the mouse to the second window it starts spitting out lots of 'd's, as if I'd still be holding down the key. Note that I can use all other applications just fine, but as soon as I move the pointer back to a gnome-terminal window chances are that it's going to continue spitting out d's until I press another key. I don't know much of the architecture so I am just guessing it's a mutter issue, bit might be gnome-shell, libinput, wayland or GTK+ for all I know. I can also observe this in epiphany (when closing the window using Ctrl-W I can get the same with the w key) and other applications. It appears that the keyboard repeat is somehow emulated in software and when closing the window the application somehow never gets the information that the key has been released in the meantime. (?) Can't reproduce this with click-to-focus.
I see that mutter seems to be indeed responsible for the focus event handling and informing wayland clients about all the details. I just figured out that it also happens in "sloppy" mode, but in a different way: In "mouse" mode it can be reproduced when either the two windows are sitting on top of another window belonging to another application or when there is just the empty desktop behind them. In "sloppy" mode the latter works just fine, but if there was a window behind (which got focussed when the window was closed using Ctrl-D), moving the mouse to another terminal window will still produce the issue. Note that the "mouse" mode seems somewhat broken since pulling the mouse out of a window and onto the desktop will still keep that window focussed and receiving keyboard events.
The issue is related to keyboard focus handling in GDK. So moving this to Gtk+.
Created attachment 312706 [details] [review] wayland: Don't ignore wl_keyboard.leave if surface is gone keyboard_handle_leave() might be called with a NULL surface resource (for example if the surface was destroyed after the event was sent). If so, we should still deal with the keyboard focus lost event, otherwise we will both leak (the keyboard_focus GdkWindow reference) and miss stopping the key repeat timer.
I can confirm that the patch fixes the issue for me.
Comment on attachment 312706 [details] [review] wayland: Don't ignore wl_keyboard.leave if surface is gone Indeed. It could be worth mentioning somewhere that gdk_window_is_destroyed() might be true on device->keyboard_focus at the time this happens, the upper layers should cope just fine with that though.
(In reply to Carlos Garnacho from comment #5) > Comment on attachment 312706 [details] [review] [review] > wayland: Don't ignore wl_keyboard.leave if surface is gone > > Indeed. > > It could be worth mentioning somewhere that gdk_window_is_destroyed() might > be true on device->keyboard_focus at the time this happens, the upper layers > should cope just fine with that though. Added a comment as you suggested. Attachment 312706 [details] pushed as dad1931 - wayland: Don't ignore wl_keyboard.leave if surface is gone