Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Sway does no properly update when a window moves into an existing container #8292

Open
WhyNotHugo opened this issue Aug 13, 2024 · 4 comments · May be fixed by #8526
Open

Sway does no properly update when a window moves into an existing container #8292

WhyNotHugo opened this issue Aug 13, 2024 · 4 comments · May be fixed by #8526
Labels
bug Not working as intended

Comments

@WhyNotHugo
Copy link
Contributor

WhyNotHugo commented Aug 13, 2024 •
edited
Loading

Version

sway version 1.10-dev-40ca4150b (Jun 10 2024, branch 'master')

Configuration

Run sway -c test.conf with the following as test.conf:

workspace_layout tabbed
exec sh test.sh

And test.sh is:

# Open five windows
foot &
foot &
foot &
foot &
foot &

sleep 1

# focus the second one
swaymsg focus left
swaymsg focus left
swaymsg focus left

sleep 1
# split it vertically
swaymsg split v

sleep 1
# focus the rightmost one
swaymsg focus right
swaymsg focus right
swaymsg focus right

sleep 1
# move it left three times
swaymsg move left
sleep 1
swaymsg move left
sleep 1
swaymsg move left

# At this point, you'll note that we should be seeing the moved window inside
# the split container, but we're actually seeing the window on the right of the
# tabbed container. The titlebar on the other hand, shows the fourth window as
# active.
sleep 5

# This properly moves the window that we've been moving all along. It will now
# be on the left of the split container.
# Everything renders correctly again at this point.
swaymsg move left

The sleeps 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 #8205, but it turns out it is a separate issue.
@WhyNotHugo WhyNotHugo added the bug Not working as intended label Aug 13, 2024
@WhyNotHugo WhyNotHugo mentioned this issue Aug 13, 2024
Closed
@WhyNotHugo
Copy link
Contributor Author

I've bisected this further:

5e18ed3cf03eee9e83909fede46dd98dff652647 is the first bad commit
commit 5e18ed3cf03eee9e83909fede46dd98dff652647 (HEAD)
Author: Ronan Pigott <[email protected]>
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

@WhyNotHugo
Copy link
Contributor Author

cc: @rpigott

@WhyNotHugo
Copy link
Contributor Author

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.

@WhyNotHugo
Copy link
Contributor Author

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);

WhyNotHugo added a commit to WhyNotHugo/sway that referenced this issue Jan 7, 2025
@WhyNotHugo
Properly focus container when it changes parent
f4e083e 
When a parented container changes parent, sway will render a sibling
non-focused container.

Fixes: 5e18ed3
Fixes: swaywm#8292
WhyNotHugo added a commit to WhyNotHugo/sway that referenced this issue Jan 7, 2025
@WhyNotHugo
Properly focus container when it changes parent
f0731de 
When a parented container changes parent, sway will render a sibling
non-focused container.

Revert deletion of code which introduced this regression.

Fixes: 5e18ed3
Fixes: swaywm#8292
@WhyNotHugo WhyNotHugo linked a pull request Jan 7, 2025 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Not working as intended
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Properly focus container when it changes parent WhyNotHugo/sway
1 participant
@WhyNotHugo