sway

commit 7f1cd0b73ba3290f8ee5f81fdf7f1ffa4c642ea7
parent f855b0898bf00285d5a7b840963b327230486632
Author: Furkan Sahin <furkansahin824@proton.me>
Date:   Tue,  8 Oct 2024 11:09:57 -0500

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
Diffstat:
M
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
@@ -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);