Initial note: This is not about focus follows mouse, which I do not use. (Everybody seems to think it is when I describe this; thus, trying to preempt confusion.)
In many applications, the mouse wheel with keyboard modifiers does something different than just the mouse wheel. Typical examples are shift+wheel scrolling horizontally and ctrl+wheel zooming in or out.
In sway, at least for me, this does not work for windows that do not have keyboard focus. Mouse wheel events are sent to the window on which the mouse pointer is (as they should), but they never receive the modifier; thus, they only see the wheel, not ctrl+wheel or shift+wheel.
The practical reproducer:
- Open an application that uses ctrl-wheel or shift-wheel for something. Examples would be firefox or chrome for ctrl-wheel zooming.
- Move focus away from that window.
- Move the mouse pointer on top of that window (but do not focus the window.)
- Holding ctrl or shift, scroll the mouse wheel.
Expected behavior:
- The application interprets ctrl-wheel and zooms in or out.
Observed behavior:
- The page open in the browser scrolls just as if only mouse wheel without ctrl had been used.
I first thought that this might be a deeper Wayland limitation, but, after reading about it, it seems that Wayland explicitly allows sending modifier events for this reason (and explains how to clear it afterwards):
https://wayland.app/protocols/wayland#wl_keyboard:event:modifiers says:
The compositor may send this event without a surface of the client having keyboard focus, for example to tie modifier information to pointer focus instead. If a modifier event with pressed modifiers is sent without a prior enter event, the client can assume the modifier state is valid until it receives the next wl_keyboard.modifiers event. In order to reset the modifier state again, the compositor can send a wl_keyboard.modifiers event with no pressed modifiers.
Initial note: This is not about focus follows mouse, which I do not use. (Everybody seems to think it is when I describe this; thus, trying to preempt confusion.)
In many applications, the mouse wheel with keyboard modifiers does something different than just the mouse wheel. Typical examples are shift+wheel scrolling horizontally and ctrl+wheel zooming in or out.
In sway, at least for me, this does not work for windows that do not have keyboard focus. Mouse wheel events are sent to the window on which the mouse pointer is (as they should), but they never receive the modifier; thus, they only see the wheel, not ctrl+wheel or shift+wheel.
The practical reproducer:
Expected behavior:
Observed behavior:
I first thought that this might be a deeper Wayland limitation, but, after reading about it, it seems that Wayland explicitly allows sending modifier events for this reason (and explains how to clear it afterwards):
https://wayland.app/protocols/wayland#wl_keyboard:event:modifiers says: