From 7f1cd0b73ba3290f8ee5f81fdf7f1ffa4c642ea7 Mon Sep 17 00:00:00 2001 From: Furkan Sahin Date: Tue, 8 Oct 2024 11:09:57 -0500 Subject: [PATCH] input/mouse: bugfix button2 being interpreted as trying to move the 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 --- sway/input/seatop_default.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/sway/input/seatop_default.c b/sway/input/seatop_default.c index 42ce333b8..d8b3b5bff 100644 --- a/sway/input/seatop_default.c +++ b/sway/input/seatop_default.c @@ -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);