Wrong keyboard event order: wl_keyboard::modifiers must be sent after wl_keyboard::enter
Affected version
OS Version: Linux jonathan-arch 5.17.1-arch1-1 #1 SMP PREEMPT Mon, 28 Mar 2022 20:55:33 +0000 x86_64 GNU/Linux
Mutter version:
Name : mutter
Version : 42.0-2
Description : A window manager for GNOME
Architecture : x86_64
URL : https://gitlab.gnome.org/GNOME/mutter
Licenses : GPL
Groups : gnome
Provides : libmutter-10.so=0-64
Depends On : dconf gobject-introspection-runtime gsettings-desktop-schemas libcanberra startup-notification zenity libsm gnome-desktop libxkbcommon-x11
gnome-settings-daemon libgudev libinput pipewire xorg-xwayland graphene libxkbfile libsysprof-capture
Optional Deps : None
Required By : gnome-shell
Optional For : None
Conflicts With : None
Replaces : None
Installed Size : 14.23 MiB
Packager : Jan Alexander Steffens (heftig) <heftig@archlinux.org>
Build Date : Thu Apr 7 05:47:57 2022
Install Date : Fri Apr 8 18:10:42 2022
Install Reason : Installed as a dependency for another package
Install Script : No
Validated By : Signature
Only happens under Wayland.
Bug summary
I was investigating a problem in wezterm1 regarding to keyboard modifiers,
and by looking at Mutter source code, I found that Mutter send wl_keyboard::modifiers
before the wl_keyboard::enter
. However, the Wayland Protocol Specification states that wl_keyboard::modifiers
must be sent after wl_keyboard::enter
2.
The relevant section of the Mutter code can be found here: meta-wayland-keyboard.c
This breaks the specification and the behavior expected by applications, I'm sure most of them does not rely on receiving wl_keyboard::enter
to track the keyboard modifier state (through wl_keyboard::modifiers
), I've been using Gnome + Mutter for one year and haven't seen this issue, specifically involving keyboard modifier state, on more than two or three applications, so I'm assuming that applications either found a workaround or doesn't depend on wl_keyboard::enter
to be able to store wl_keyboard::modifiers
values.
However, this is messing with wezterm keyboard state tracking, since it needs to have a surface before it can forward the events, also, when focusing out and in, Mutter sends the event in the wrong order (wl_keyboard::modifiers
before the wl_keyboard::enter
), and every wl_keyboard::enter
clears the keyboard state on the wezterm side, and since wl_keyboard::modifiers
was sent before the wl_keyboard::enter
(which is a non-spec compliant behavior), it loses track of the modifiers state (such as Num Lock), and treat like all them were off (Num Lock, Caps Lock, ...).
I don't know which other applications may have issue with this behavior (I've seen this problem with two apps at least), but looking into other Wayland compositors, it looks like they are sending the events in the right order345.