Signal window_created does not always fire for windows created on application launch

[dominiklohmann]

Bug report

For some applications, windows created (restored?) when launching applications are not firing event=window_created signals.

I can reliably reproduce this with System Preferences.app.

# this does not trigger when opening system preferences
yabai -m signal --add event=window_created action="terminal-notifier -message test"

[koekeishiya]

macOS don't send window_created notifications for these windows as far as I know, and I don't want to make yabai's internal signals cross that event boundary. Could you not register for app launch and query windows for that application using the pid?

[dominiklohmann]

Sure thing, just considered this a bug.

You can always do this, with the downside of needing a sleep because windows may be created after the application is launched.

yabai -m signal --add event=application_launched \
    action='sleep 0.5 \
        && yabai -m query --windows \
            | jq ".[] | select(.pid | tostring == env.YABAI_PROCESS_ID).id" \
            | xargs -I{} terminal-notifier -message {}'

Also I noticed that I get the event=application_launched signal multiple times. Something seems really wrong with it. For System Prefs it fires 4 times, for Preview it fires 3 times.

# process id will show up multiple times in stdout
yabai -m signal --add label=test event=application_launched \
    action="echo \$YABAI_PROCESS_ID"

Edit: For example, I just opened Preview with a slightly modified script running and had this in my log:

querying pid 21646
querying pid 21646
querying pid 21646
found wid 3143
found wid 3143

So I get the event=application_launched signal 3 times and action on every window twice, because for the first trigger the window was not yet available in the queries.

I think this really shows why this method is unreliable.

[koekeishiya]

Also I noticed that I get the event=application_launched signal multiple times. Something seems really wrong with it. For System Prefs it fires 4 times, for Preview it fires 3 times.

Fixed on master. See #175

[dominiklohmann]

So the fix in #175 actually fixed the unreliability issue with the window id's as well. That's good.

Now it's just a matter of discussing whether windows created during the application launch should be triggering a window_created event or not.

[koekeishiya]

I personally prefer that signals mirror what macOS reports to us. I have had a lot of bad experience in the past trying to do otherwise.

[dominiklohmann]

I feel like I'm doing something horribly wrong, because my action works when executed from a file but not when inline (re: confusion in #177 / from #167). Maybe you know what's up here.

yabai -m signal --add event=application_launched label=test action="yabai -m query --windows | jq -r '.[] | select(.pid | tostring == env.YABAI_PROCESS_ID)'"
# fails with this is on stdout
# sh: -c: line 0: unexpected EOF while looking for matching `''
# sh: -c: line 1: syntax error: unexpected end of file

# this works
export YABAI_PROCESS_ID=19210 && yabai -m query --windows | jq -r '.[] | select(.pid | tostring == env.YABAI_PROCESS_ID)'

# this works as well
/usr/bin/env YABAI_PROCESS_ID=19210 sh -c "yabai -m query --windows | jq -r '.[] | select(.pid | tostring == env.YABAI_PROCESS_ID)'"

[koekeishiya]

There is currently a cap of how many bytes yabai will read from the socket, and you are likely exceeding that cap when inlining the script this way.

[dominiklohmann]

So this should print an error when trying to add the signal and support way longer signals, especially considering the example for acting on window ids from an event=application_launched signal is already too long.

[koekeishiya]

So this should print an error when trying to add the signal and support way longer signals, especially considering the example for acting on window ids from an event=application_launched signal is already too long.

The correct solution here is to simply remove the message cap.

[dominiklohmann]

I'm closing this in favour of a newly created issue (#221). Will document this behaviour.

[koekeishiya]

Turns out this issue was not because of a message cap, but because I was using the c-std function strtok for parsing key-value pairs. The command you posted had an equals in it, which of course strtok splits on, as it simply splits the input string.. Added #307