Properly focus container when it changes parent

[WhyNotHugo]

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: #8292

[WhyNotHugo]

Kind bump? This is a really annoying regression since 1.10.

[Nefsen402]

It seems this behavior is intended by the "regression" PR, which claims that this behavior is correct for i3.

[WhyNotHugo]

This was not reproducible on i3 last I checked.

Have you reproduced the bug yourself? When moving windows through a tabbed container, sway will at some point render another window, while indicating that the one being moved is still focused.

The commit that broke this says:

My code archaeology isn't good enough to determine what this is here for, but it isn't correct.

I've found why this code is here, if fixes this particular issue. Maybe i3 doesn't need it because this corner case is handled elsewhere, I have no idea.

[WhyNotHugo]

Here's a video reproducing the behaviour:

https://mirror.whynothugo.nl/t/sway-issue-8292.mkv

I start out with a tabbed container with:

• One terminal (1)
• A horizontal split with a single terminal (2)
• One terminal (3)
• One terminal (4)
• One terminal (wf-record)

I focus terminal (4), and move it left two times. It is now inside the horizontal split, sway marks the horizontal split as focused, but renders the surface from the wf-record window.

I then type swaymsg move left. You can't see me type this, but it gets typed into the window that isn't being rendered (e.g.: it's not visible but still has keyboard focus). You can see it appear again after I move it left two more times. The first time it is moved to the left side of the horizontal split, the second time it is moved out of the split.

[Nefsen402]

Huh, yeah this is definitely a real issue. I find it strange that it doesn't render anything at all, focusing/unfocusing shouldn't affect rendering to this extent.