`skip_window_focus_animation` incorrectly switches spaces when interacting with a sticky / PiP window
Description
When skip_window_focus_animation is enabled, interacting with a sticky window can unexpectedly switch to another space. A reliable way to reproduce this is using Google Chrome with a YouTube Picture-in-Picture window. The PiP window is visible on the currently focused space, and yabai reports it as "is-sticky": true. However, the "space" reported for that window is sometimes different from the currently focused space. When clicking the PiP window or interacting with some of its controls, yabai immediately switches to the space reported for that window. Disabling skip_window_focus_animation completely avoids the problem.
This may be related to #2781 and possibly #1835.
Environment
- yabai version:
v7.1.25 - macOS version:
macOS 15.6 - SIP: enabled
- Scripting Addition: not loaded
Steps to reproduce
Create at least two macOS spaces.
Enable:
yabai -m config skip_window_focus_animation onOpen a PiP window.
Switch to another space. The PiP window remains visible there as expected.
Query the PiP window with yabai. It is reported as sticky, for example:
{
"space": 3,
"is-visible": true,
"is-floating": true,
"is-sticky": true
}The value of "space" is not necessarily the currently focused space.
- Click the Picture-in-Picture window or one of its controls.
Actual behavior
The focused space immediately changes to the space associated with the PiP window by yabai, even though the sticky window was already visible on the currently focused space.
Expected behavior
Interacting with a sticky window that is already visible on the currently focused space should focus/interact with that window without changing spaces. skip_window_focus_animation should only bypass the animation when focusing a window actually requires switching to an inactive space.
Workaround
Disabling the option fixes the issue:
yabai -m config skip_window_focus_animation offWith the option disabled, clicking and interacting with the same PiP window does not change the current space.
Additional observation
This may be caused by sticky windows being associated with a space that is different from the currently focused space, even though the window is already visible on the current space.
A possible fix might be to skip the space-switch / animation-bypass logic for sticky windows. Since a sticky window is already visible across spaces, focusing or interacting with it should normally not require switching to its reported space. Alternatively, the implementation could first check whether the target window is already visible on the currently focused space before initiating a space switch.
Source: asmvik/yabai