Focused window origin display doesn't work correctly

[kabeersvohra]

I have been trying to fix why my windows were not opening on the display with the current focus even when I had set window_origin_display set to focused. I created these two signals in my yabairc:

yabai -m signal --add event=display_changed \
      action="echo \$YABAI_DISPLAY_ID > /tmp/yabai_current_display"

yabai -m signal --add event=space_changed \
      action="echo \$YABAI_SPACE_ID > /tmp/yabai_current_space"

and it turns out that for me the values seem quite wrong, please see attached screenshots. I think that this is also affecting the window origin display since they are based on the same values from looking at the code.

For context, I only have 2 displays, one thing that I have noticed that is consistent so far is that the primary display is always number 1, but the secondary display can be arbitrarily high as a number. The spaces seem to be harder to notice a pattern for

[kabeersvohra]

I have noticed the issue, it outputs the id of the current space from yabai -m query --spaces rather than the index of the space. And then the focussing in window_origin_display happens based upon the index of the space

[lethefrost]

Is this issue #1900 related?

[kabeersvohra]

@lethefrost no that seems to be an issue of a space being inserted in the general order, however this is about the space index vs id being switched in the source code

[lethefrost]

@lethefrost no that seems to be an issue of a space being inserted in the general order, however this is about the space index vs id being switched in the source code

thanks for clarifying!

[gldtn]

I have been noticing this weird issue as well, but figured it's something with the new update and I didn't update my yabairc correctly. Sometimes a window opens and it does not focus when I have it set to a specific space. Also when simply switching/focusing with alt - 0 : yabai -m space --focus 10 on my second monitor to be specific it does not focus or it randomly switches to a space between 5-9, but I have to do some more testing to see exactly what is going on.

[kabeersvohra]

For clarity I am using this script at the moment which is able to replace the window_origin_display setting, however it is causing a lot of flickering since it needs to move the window after it has already been created. I can't seem to work out how this translates into a fix for the code however.

#!/bin/bash

current_display=$(cat /tmp/yabai_current_display)
window_app=$(yabai -m query --windows --window $YABAI_WINDOW_ID | jq -r '.app')

if [ "$window_app" != "Notification Centre" ]; then
    yabai -m window $YABAI_WINDOW_ID --display $current_display --focus
fi

yabai -m signal --add event=window_created action="~/config/dotfiles/config/yabai/move_to_current_display.sh"

[kabeersvohra]

@koekeishiya just wondering if you had any ideas on the above? As a result I can't seem to get the window_origin_display working well at all. The signal I have above works, but it causes so much movement of windows across different displays all the time. Thank you

[koekeishiya]

Make sure you use the correct value; signals only provide the internal id at this time. You can use the query system to retrieve the other index. The id in the query result is an internal id given by the system, and index is the user facing identifier (mission control index, display arrangement) that is given to yabai commands.

I should probably allow both type of identifiers to be given to the commands, or provide the user facing identifier in signals.

[kabeersvohra]

Thanks @koekeishiya. After some testing I discovered the issue with the 'window_origin_display' here. Basically what happens is that when a window is spawned, there is some kind of race condition with the window spawning to a particular space and then 'yabai' grabbing what the currently 'focused' or 'cursor' space is. Therefore this behaviour becomes non-deterministic and sometimes it moves the window to the space before the window was created and sometimes it keeps it on the same space that the window is created on by MacOS. Therefore I think that the only real solution to this is https://github.com/koekeishiya/yabai/issues/1605

Thanks for all your work!

[koekeishiya]

Can you make a screenrecording showcasing the issue you are having with the built-in window_origin_display configuration (without signals interfering).

[kabeersvohra]

Sure I will do, I won't be back at my laptop until the 1st so will do it then. Have a good new years until then

[koekeishiya]

If you can enable debug_output as well, and post the log alongside the recording that would be great.

[kabeersvohra]

I have done so and uploaded here :) debug_output.txt

https://github.com/koekeishiya/yabai/assets/5859986/b96f6843-d56b-4f51-b9a9-769b957bd9c2

[koekeishiya]

Right so I think what is going on is that macOS needs to focus the application before it can create new windows, and in some cases yabai gets this "space changed" event before the "window created" event, so that the "focused space" according to macOS (which yabai then reads and caches) is not the space the user was focused on when the command to create a new window was executed.

I am not completely sure how to fix this at this moment, but I would classify this as a bug and I'll look into it. I think this should be possible to solve with some creativity.

Meanwhile you could try to use "cursor" instead of "focused" and I believe that should work, as long as you are able to have the cursor be located on the correct display upon command execution.

[kabeersvohra]

Ah yes that makes sense, in case it’s any use this is my current workaround:

capture_current_display.sh:

#!/bin/bash

display_index=$(yabai -m query --displays | jq --arg id "$YABAI_DISPLAY_ID" '.[] | select(.id == ($id | tonumber)).index')
echo $display_index > /tmp/yabai_current_display

move_to_current_display.sh

#!/bin/bash

current_display=$(cat /tmp/yabai_current_display)
window_app=$(yabai -m query --windows --window $YABAI_WINDOW_ID | jq -r '.app')

move_apps=("Firefox" "kitty" "Slack")

if [[ " ${move_apps[@]} " =~ " ${window_app} " ]]; then
    yabai -m window $YABAI_WINDOW_ID --display $current_display --focus
fi

yabairc

yabai -m signal --add event=display_changed action="~/config/dotfiles/config/yabai/capture_current_display.sh"
yabai -m signal --add event=window_created action="~/config/dotfiles/config/yabai/move_to_current_display.sh"

I guess that capture action takes long enough that it doesn’t write out to the temporary file before the move action takes place in the scenario you describe. However with this approach there is a lot of flickering as the window is tiled on one display and then moved, often causing there to be an empty space on the source display as seen in the video.

I am also unsure on what code changes could be made in this case, however happy to give a PR a go if you have any ideas.

[kabeersvohra]

hey @koekeishiya, I was wondering if you had an idea on how we could solve this issue? I would be willing to give it a try but I am not sure about the underlying Mac OS events that get triggered that I should listen for? Thanks a lot :)