shift+command+w close current window on vscode does not trigger relayout

[eret9616]

In VSCode, pressing Shift + Cmd + w to close the current window doesn’t trigger a relayout

yabai:
yabai-v7.1.3

vscode:
code 1.88.1
e170252f762678dec6ca2cc69aba1570769a5d39
arm64

Reproduction steps:

1.	Open iTerm terminal and place it on the left side, open VSCode and place it on the right side.
2.	Focus on VSCode, then press Shift + Cmd + W to close the VSCode window.
3.	The windows do not reallocate.

[penamimax]

I'm facing the same issue with pretty much every program. I.e., I can't name a single program where this doesn't happen.
Also on yabai-v7.1.3 on MacOS 15.0.

Switching spaces back and forth on the specific display where the empty space remained seems to cause Yabai to relayout and fill the empty space again.

It might be related to issue #2426 . Just that it seems way more widespread.

[Liquidmantis]

Oooh, turned out to be Contexts for me, too. That sucks, but I don't use Contexts that heavily anyway.

[penamimax]

This is puzzling. It almost is as if Yabai lost the ability to detect windows being closed on my system.
I don't use Contexts, but Phoenix (https://github.com/kasper/phoenix) and unfortunately I use that extensively.

E.g., I even replaced skhd with phoenix since I was already using for various other tasks, like manual tiling when not using Yabai's bsp window arrangement.

I can confirm that disabling phoenix makes Yabai detect closed windows again.

Issue #2324 describes why this happened.

So bottom line, it seems like we can only use one window arranging program at a time, even if the two are not actively arranging windows at the same time. That's unfortunate.

Since this is a MacOS based change, don't feel obligated to keep that issue opened on my behalf.

Edit: phoenix doesn't seem to have the issue that yabai has, but then again I use different functionality in each. So it's not straight forward to tell if it's unaffected for sure.

[eret9616]

Today I tried to disable the context, and I found that installing and using Amazon Q also causes this issue…

[koekeishiya]

Try the latest commit (6f9006d) from master; I've implemented a compatibility workaround/fix, but this is either a system-issue caused by an Apple bug, or a bug triggered by the other third-party software somehow. I don't know how contexts or amazon q works.

[koekeishiya]

Just did a release after testing the changes; v7.1.4.

[johnnyBira]

I just updated to v7.1.4, and this is still a problem for me on Sequoia.
https://github.com/user-attachments/assets/e3057220-308c-4a87-9b70-a6a3cd76ba71

[raoulkent]

That's odd, I've installed latest and it works fine, super snappy again
(Yabai 7.1.4, Sequoia 15.0 on M1 Pro)

[eret9616]

what I still find the problem is autofocus still fail after some operations.. but i haven't figure out how to reproduce it ..

[koekeishiya]

I just updated to v7.1.4, and this is still a problem for me on Sequoia. https://github.com/user-attachments/assets/e3057220-308c-4a87-9b70-a6a3cd76ba71

I tested it on my 15.0 instance and it worked fine in v7.1.4 (v7.1.3 had the issue) and other people have also reported the new version fixing the issue for them, so realistically I am going to need something more specific than "still a problem" if you want me to be able to do something here.

[matzegebbe]

for me it also works fine now. Thank you @koekeishiya

[johnnyBira]

After my comment I tried it with other apps, and it works with all of them, except for Wezterm as demonstrated in my comment video attachment.
Before it was a problem with all apps, so I'm not sure what's different about Wezterm. Switching between workspaces refreshes the layout and makes the windows (even Wezterm) behave as they should.

Thank you for all your effort, the last release was a great improvement.

[Liquidmantis]

I still see this when Contexts is running, unfortunately. I've experienced it on both my personal MBP with SIP disabled after upgrading to Sequoia, and once Sequoia was cleared on my work MBP, I started experiencing it there. SIP is enabled on my work MBP.

It seems any operation that reduces available space works, e.g. opening a new window or popping out a browser tab will trigger a layout change. Actions that would cause a window to expand fail some percentage of time. I'd guess something like 10-25%, but that's a very rough estimate. Things like minimizing or closing a window will leave an empty spot in the window layout. Switching to another Mac Space and back will however trigger a refresh and the tiling "heals". I can't remember at this point how that compares before the patch above, but it must have been a lot more frequent prior because it definitely seemed like things were working in harmony. Contexts is stable and hasn't updated for a couple of years now, so that's not the delta.

For me it's absolutely reproducible with Contexts running. I've quit using it on my personal MBP as a result and will give it up on my work one now, as it's loss doesn't impact me much.