mirrors/sway
1
0
Fork 0
mirror of https://github.com/swaywm/sway.git synced 2026-04-17 06:46:32 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

input/mouse: bugfix button2 being interpreted as trying to move the

Browse source 
container.

Man sway(5) specifies that when tiling_drag is enable, the floating_mod
can be used to drag tiling, as well as floating containers. However the
current code indiscriminately assumes any button press to be intended
for moving the container, consequently causing an unintended call to
`seatop_move_tilting:handle_button` rather than
`seatop_default:handle_button` to pass
`state=WL_POINTER_BUTTON_STATE_RELEASED` to `get_active_mouse_binding`

My idea was to make 'Handle moving a tiling container' follow the same
path as 'Handle moving a floating container' because the initial call
to handle moving a floating correctly exits that branch and ends up
passing the RELEASED state to `get_active_mouse_binding`.

Fixes #8334
This commit is contained in:
Furkan Sahin 2024-10-01 10:35:59 -05:00
parent 9a9be01ad4
commit 77d55cccc5
1 changed files with 3 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

4
sway/input/seatop_default.c
View file

@ -491,7 +491,9 @@ static void handle_button(struct sway_seat *seat, uint32_t time_msec,
// Handle moving a tiling container
if (config->tiling_drag && (mod_pressed || on_titlebar) &&
state == WL_POINTER_BUTTON_STATE_PRESSED && !is_floating_or_child &&
cont && cont->pending.fullscreen_mode == FULLSCREEN_NONE) {
cont && cont->pending.fullscreen_mode == FULLSCREEN_NONE &&
button == (config->floating_mod_inverse ? BTN_RIGHT : BTN_LEFT)) {
// If moving a container by its title bar, use a threshold for the drag
if (!mod_pressed && config->tiling_drag_threshold > 0) {
seatop_begin_move_tiling_threshold(seat, cont);