Open WhyNotHugo opened 2 months ago
I've bisected this further:
5e18ed3cf03eee9e83909fede46dd98dff652647 is the first bad commit
commit 5e18ed3cf03eee9e83909fede46dd98dff652647 (HEAD)
Author: Ronan Pigott <ronan@rjp.ie>
Date: Wed Feb 28 17:51:03 2024 -0700
commands/move: do not force focus on the moved container
My code archaeology isn't good enough to determine what this is here
for, but it isn't correct. We should be able to move containers in a
direction without focusing them. AFAICT i3 doesn't do this, so we
shouldn't either.
This fixes ipc commands like move <dir> with criteria that apply to
containers which are not the current focus.
sway/commands/move.c | 9 ---------
1 file changed, 9 deletions(-)
Using wlroots 2a897af7dc532a3585401ae317d586a69c1af1d3
cc: @rpigott
I didn't properly clarify this above: when this issue is triggered, the tab bar shows the right-most window as focused, but another window has focus (and responds to keyboard input and to swaymsg move
commands).
However, the window that is rendered inside the tabbed container is different from the focused one.
Restoring the following two lines fixes the issue:
seat_set_raw_focus(config->handler_context.seat, &new_ws->node);
seat_set_focus_container(config->handler_context.seat, container);
Version
sway version 1.10-dev-40ca4150b (Jun 10 2024, branch 'master')
Configuration
Run
sway -c test.conf
with the following astest.conf
:And
test.sh
is:The
sleep
s are there to ensure that all commands execute before proceeding. They also help visualise the issue.Description
When I move a window into a split container, the view doesn't properly update, and I see the wrong window, while sway shows the wrong titlebar as active. Moving that window again restores sway to a consistent state.
I recommend running the above reproductions script while reading through the script as actions progress.
Additional notes
I previously mentioned this in https://github.com/swaywm/sway/issues/8205, but it turns out it is a separate issue.