GNOME Bugzilla – Bug 775905
GTK3 applications swallow hotkeys intended for GTK2 applications on Wayland
Last modified: 2016-12-29 08:59:01 UTC
I use Clipit which is a GTK2 clipboard manager and it can no longer capture it's hotkey over some native GNOME GTK3 application windows such as gnome-terminal or nautilus or terminator which was recently upgraded to use GTK3. This only happens when using Wayland. If I switch to GNOME/X11 the issue goes away. Version-Release number of selected component (if applicable): clipit-1.4.2-11.fc24.x86_64 gnome-terminal-3.22.1-1.fc25.x86_64 terminator-1.90-1.fc25.noarch gtk3-3.22.4-1.fc25.x86_64 GNOME Shell 3.22.2 with Wayland How reproducible: Always Steps to Reproduce: 1. Launch clipit 2. Launch gnome-terminal or terminator or nautilus 3. Focus on one of the apps above and issue the hotkey. Actual results: The clipit history hotkey does not work. Gnome Terminal issues an error bell sound and if you have a program running using the hotkey (ALT Z in my case) it will print ^[z to the terminal screen. Nautilus does nothing. Having Chrome, Firefox, Spotify or any other non native GNOME application as the main focus, clipit will be able to capture the hotkey and bring up the clipboard history dialog menu. Expected results: GTK3 apps to stop swallowing hotkeys. Additional info: Downgrading to terminator-0.98-4.fc25 which is based on GTK2 seems to allows for clipit to capture it's hotkey when focused on terminator window and it brings up the clipboard history. Compiling clipit from source with DEBUG set in the keybinder.c file you can see it is able to capture the keypress but when focused on gnome-terminal it never sees the keypress and you hear the error bell from gnome-terminal. $ ./src/clipit Got accel 122, 8 Got keycode 52 Got modmask 8 Got accel 97, 12 Got keycode 38 Got modmask 12 Got accel 112, 12 Got keycode 33 Got modmask 12 Got accel 102, 12 Got keycode 41 Got modmask 12 Got accel 111, 12 Got keycode 32 Got modmask 12 Got Event! 2, -1 Got KeyPress! keycode: 52, modifiers: 8 Calling handler for '<Alt>Z'... Got Event! 2, -1 Got KeyPress! keycode: 52, modifiers: 8 Calling handler for '<Alt>Z'... Got Event! 2, -1 Got KeyPress! keycode: 52, modifiers: 8 Calling handler for '<Alt>Z'... Got Event! 2, -1 Got KeyPress! keycode: 52, modifiers: 8 Calling handler for '<Alt>Z'...
This is the intended behavior; it's by design that arbitrary clients cannot eaves drop on keys from other clients. The reason why it happens to work sometimes is that GTK2 clients still use X11, meaning the eaves dropping still works when interacting with X11 clients via Xwayland. When focusing a GTK3 client, it connects via Wayland, and as a result, Xwayland will not be able to broadcast input to all clients wanting it any more, since it wont see the input events at all. In Wayland, the clipboard manager has to be part of the compositor.
Thanks for clearing this up Jonas. I will update my bug on on RHBZ and notify the developer of Clipit. Happen to know of a good Wayland compatible clipboard manager? :)
(In reply to Joe Doss from comment #2) > Thanks for clearing this up Jonas. I will update my bug on on RHBZ and > notify the developer of Clipit. Happen to know of a good Wayland compatible > clipboard manager? :) It'll have to be part of the compositor, i.e. a mutter feature in the GNOME context. The code is slightly prepared for this, but exactly how it would work I'm not sure.