mirror of
https://github.com/swaywm/sway.git
synced 2024-11-23 16:31:29 +00:00
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
This commit is contained in:
parent
f855b0898b
commit
7f1cd0b73b
|
@ -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);
|
||||
|
|
Loading…
Reference in a new issue