The bug can be reproduced by using the following keybinds and then taking
the steps below with an XWayland client, for example xterm:
<keybind key="C-S-h">
<action name="GoToDesktop" to="left" wrap="yes"/>
</keybind>
<keybind key="C-S-l">
<action name="GoToDesktop" to="right" wrap="yes"/>
</keybind>
1. Press C-S-h
2. Press C-S-l
3. Observe llllllll.... in xterm
Store the key-state in `handle_keybind()` before any call to
`action_run()` as this may lead to `seat_focus()` which passes
'pressed-sent' keys to the new surface.
This partially reverts 7571c4b, which as a standalone commit was fine, but
when 'pressed_mods' were then included in 'bound' in 98bf316,
`key_state_store_pressed_keys_as_bound()` was again required in
`handle_keybind()` to ensure modifers are not passed as non-modifiers in
`wlr_seat_keyboard_notify_enter()` in `seat_focus()`
This prevents applications from seeing and handling the release event
for a modifier key that was part of a keybinding (e.g. Firefox displays
its menu bar for a lone Alt press + release).
These exceptions were added to prevent certain keys (modifiers and
synthetic layout switch key-events) from disabling keybindings (due to
the "nr_pressed_keys > 1" check). That check no longer exists, so the
exceptions should no longer be necessary.
Partially reverts e77330bc3f and 3e2baa3f05.
This restriction should be unnecessary now (see the previous commit for
details) and caused issues with keybindings not working on some systems
where irregular keypress events are received (e.g. XF86XK_WakeUp)
without an accompanying release event.
Kept separate from the previous commit for the sake of potential future
bisects.
Partially reverts e77330bc3f.
Before commit e77330bc3f, there were issues with keys becoming "stuck"
if other keys were pressed at the time a keybinding was matched, because
those other keys were included in the "bound" set and the release events
were incorrectly eaten by labwc.
Commit e77330bc3f solved that issue with the "big hammer" approach of
preventing keybindings from working at all if other keys were pressed:
if (key_state_nr_pressed_keys() > 1) {
return false;
}
This is an alternate approach to solving the original problem, by (1)
not including those other keys in the "bound" set and (2) making sure we
always forward release events for un-bound keys to clients (even if a
menu or OSD is displayed).
Details:
- Since we only ever want to store the single matched keycode as bound,
key_state_store_pressed_keys_as_bound() doesn't really make sense in
the plural, so rename it to key_state_store_pressed_key_as_bound() and
pass in the keycode.
- The calls to key_state_store_pressed_keys_as_bound() within
handle_keybinding() appear to be redundant since it is also called
from the parent function (handle_compositor_keybindings()). So remove
these calls.
- Finally, rework the logic for handling key-release events so that we
always forward release events for keys not in the "bound" set.
This PR does not remove the "key_state_nr_pressed_keys() > 1" check, and
because of that should not result in any functional change. It should
however make it possible to relax or remove that check in future.
Remove wlr_seat_set_keyboard() from `keyboard_modifiers_notify()`
but leave it in `keyboard_key_notify()`
Fixes regression introduced in 984aeb0
Reported-by: @jlindgren90
Fixes: #1238
Fixes#1076
It can be enabled with a config like
~/.config/labwc/rc.xml:
<keyboard layoutScope="window">
~/.config/labwc/environment:
XKB_DEFAULT_LAYOUT=de,us
XKB_DEFAULT_OPTIONS=grp:alt_shift_toggle,grp_led:scroll
With a configuration like this each window should now remember
the active keyboard layout when switching between windows.
By default, the keyboard layout keeps being a global state.
We already allow some xwayland-unmanaged surfaces to take focus on map,
if indicated by wlr_xwayland_or_surface_wants_focus(). But once these
surfaces lose focus, they never regain it again.
Add desktop_focus_view_or_surface() and call it in the appropriate
places to allow these views to regain focus in the usual ways (e.g.
clicking on them or focus-follows-mouse).
