]> git.mdlowis.com Git - proto/labwc.git/commit
seat: prevent Chromium from crashing when active keyboard is gone
authortokyo4j <hrak1529@gmail.com>
Mon, 6 May 2024 14:53:18 +0000 (23:53 +0900)
committerJohan Malm <johanmalm@users.noreply.github.com>
Wed, 8 May 2024 19:39:09 +0000 (20:39 +0100)
commitcafdcd8e19c99d141afb5a631d1eaadad0a9f5f4
treeb7ea603bb4f711f1466fdc13e04e6d79d49eb131
parent097ac44edafa95fbe9aee15eea51e20beafbabba
seat: prevent Chromium from crashing when active keyboard is gone

Chromium (and slurp) expect wl_keyboard.keymap event to be sent before
wl_keyboard.modifiers event. Normally, wl_keyboard.keymap event is sent
on the client first obtains wl_keyboard with wl_seat.get_keyboard
request.
However, after the active (especially virtual) keyboard is destroyed,
wlroots doesn't respond to wl_seat.get_keyboard request with
wl_keyboard.keymap event since there's no active keyboard on the seat.

Therefore, if we run commands like "sleep 2; wtype hello; chromium", the
active keyboard is destroyed when wtype finishes and
wl_keyboard.modifiers event is sent to Chromium when Chromium first maps
the surface and the keyboard focus is moved to it, then Chromium crashes.

With slurp, fcitx5 and multi-monitor setup, a similar thing happens.
When slurp first creates the layer-shell surfaces, the focus moves to it
(without wl_keyboard.enter though), and fcitx5 is transiently deactivated
and it destroys the virtual keyboard. Then when slurp maps those
surfaces, the focus moves between them again and wl_keyboard.modifiers
event is sent, thus slurp crashes.

So with this commit, when the active keyboard on the seat is destroyed,
the keyboard from the keyboard group is set to the seat instead so
wlroots can respond to wl_seat.get_keyboard request with
wl_keyboard.keymap.
src/seat.c