Chrome "app" closing on focus via Yabai

[bcspragu]

This is a strange bug that started manifesting recently, I don't know if it's a yabai issue, a Chrome issue, both, or neither. Steps to (hopefully) reproduce:

1. Take a page in Chrome (I've tested with Google Calendar + GitHub, but it seems page-independent)
2. Go to Chrome three dot menu > Cast, Save, and Share > Install <app name>
3. The Chrome app opens in a new window
4. Focus to it with yabai (i.e. using a keyboard shortcut)

The window will reliably, 100% of the time, close. If I click the window to focus it with my mouse, it's fine. If I use Yabai to focus away from the Chrome app, or to move windows around, etc, it's fine, normal behavior. But focusing from an adjacent app to a Chrome app window will cause it to close. I accidentally do this a dozen times a day (open Google Calendar Chrome app, try to focus it with keyboard shortcuts, it closes)

This doesn't happen with other windows (i.e. non-Chrome macOS apps like terminals, editors, etc, etc), I can give them focus with the keyboard just fine. But it didn't used to be an issue with Chrome apps either until recently (maybe the last time I updated yabai?)

Also, a point of clarification in case it isn't clear, I'm using "Chrome app" to mean "website 'installed' via Chrome to act like a native application", so it shows up in Spotlight, and renders without a URL bar or normal browser window chrome.

I'm running yabai-v7.1.25, the latest, on macOS Tahoe, Version 26.5.1 (25F80)

[bcspragu]

Doing some LLM-fueled debugging, this patch seems to fix the issue for me:

diff --git a/src/window_manager.c b/src/window_manager.c
index 13bc2458a9..706110a2f7 100644
--- a/src/window_manager.c
+++ b/src/window_manager.c
@@ -1276,12 +1276,23 @@
     // event-tap is placed at the point where session events have been
     // annotated to flow to an application.
     //
+
+    double location = -1e6;
 
     memset(g_event_bytes, 0, 0xf8);
     g_event_bytes[0x04] = 0xf8;
     g_event_bytes[0x3a] = 0x10;
     memcpy(g_event_bytes + 0x3c, &window_id, sizeof(uint32_t));
-    memset(g_event_bytes + 0x20, 0xff, 0x10);
+    memcpy(g_event_bytes + 0x20, &location, sizeof(double));
+    memcpy(g_event_bytes + 0x28, &location, sizeof(double));
 
     g_event_bytes[0x08] = 0x01;
     SLPSPostEventRecordTo(window_psn, g_event_bytes);
diff --git a/test.patch b/test.patch
new file mode 100644
index 0000000000..e69de29bb2

(the comment directly above the patched lines would also need updating if this approach makes sense)

As far as I can tell, the issue is a change in how Chrome PWAs handle some incoming events. Changing the event location from NaN to somewhere way off screen stops Chrome from killing the process.