🐞 PWA Crashes when Using Loop

[jvanderen1]

Bug Description

I notice if I use any PWA and try to vertically snap via Loop, the application I am resizing crashes.

Affected Scope

Crash / Freeze

Steps to Reproduce

1. Get a PWA (e.g., Google Keep, Google Chat, etc.)
2. Drag application vertically for vertical snapping

Reproducibility

Often (≥70%)

Expected vs Actual Behavior

Expected

Vertically snaps just fine

Actual

Application crashes

Screen Recordings / Screenshots

output.mp4

Severity

Major (workaround exists)

macOS Version

Tahoe 26.6 (25G72)

Loop Version

Version 🧪 1.4.3 (1755)

Did You Try the Development Build?

Yes

Additional Context

No response

Final Checks

• My issue is written in English.
• My issue title is descriptive.
• This is a single bug (multiple bugs should be reported individually).
• I have looked to see if this is a duplicate of another bug report.
• I can help with further investigation.
• I can help with developing a fix for this issue.

[mrkai77]

I’m currently unable to reproduce this bug on my machine, but since you mentioned you might be able to help develop a fix, I was wondering if you have any ideas what could be causing it? Or if you already have a fix in mind, I’d be happy to hear your thoughts!

If not, it may also be worth trying to toggle window animations, since that changes how windows are handled slightly.

[jvanderen1]

@mrkai77 I will spend some time today to see if I can isolate the root cause of the issue. Thanks for being super responsive!

OOC, when are you guys planning on officially releasing the latest binary? There are a lot of updates in the pipeline already and I would hate for non-beta users to be surprised by the amount of updates.

[jvanderen1]

Investigation update

Root cause appears to be on the Chromium PWA shim side under Loop's non-animated AX resize path — not Loop crashing, and not all PWAs.

Isolation results

Case	Result
Chrome / Brave PWA (Keep, Chat, ...) + any snap (top / side / corner)	Crash
Keybind / radial (no drag)	Crash
Animate window resize off	Still crashes
Chrome / Brave browser windows	OK
Safari Keep PWA	OK
TextEdit	OK

Loop path

WindowActionEngine → WindowEngine.resizeWindow (non-animated) does setFrame, then a second setFrame when the frame doesn't stick, then handleSizeConstrainedWindow may setPosition again. Chromium *.app.<id> shims (e.g. com.brave.Browser.app.…, com.google.Chrome.app.…) appear fragile under that AX flood.

Loop fix (in progress on fix/1131-pwa-vertical-snap-crash)

For Chromium PWA shims only: single sizeFirst setFrame, skip the retry; still one constrained-origin correction. Parent Chrome/Brave windows keep the existing path.

Chromium upstream (follow-up)

Worth filing at https://issues.chromium.org with a crash .ips attached. Suggested details:

• macOS Tahoe version + Chrome/Brave version
• Repro: install Keep/Chat as Chrome/Brave PWA → snap with a window manager via AX kAXPosition/kAXSize
• Controls: Safari PWA + parent browser windows do not crash
• Link this issue

I'll cross-link the Chromium ticket here once filed.

[jvanderen1]

Upstream status:

• Public Chromium report (Cmd+Tab / canBecomeKeyWindow → app_shim channel error):
  https://issues.chromium.org/issues/539984770
• That issue is marked duplicate of a restricted canonical bug:
  https://issues.chromium.org/issues/537448007 (not publicly viewable)

Our Console sequence hits the same app_shim_controller.mm:679 Channel error sink, but via AX resize (kAXSize / kAXPosition) rather than only Cmd+Tab. I left a comment on 539984770 with that repro.

Loop workaround: #1132
(ChromiumPWAResizeWorkaround — removable once Chromium ships a fix)

[HuAustin]

I’m experiencing what appears to be the same issue, with a different trigger and macOS version.

Environment:

• macOS 15.7.5 (24G624)
• Microsoft Edge-installed PWA
• Loop 1.4.2 (1693)
• Also reproduced with Loop 1.4.3 development build (1755)

Reproduction:

1. Open and focus an Edge-installed PWA.
2. Trigger any Loop keyboard shortcut that moves or resizes the window.
3. The PWA immediately disappears/closes and is shown as no longer running.

This occurs consistently with multiple Loop shortcut configurations. The same shortcuts work normally with native macOS applications.

Therefore, the problem does not appear to be limited to vertical drag snapping or macOS Tahoe. It is also reproducible through keyboard shortcuts on macOS 15.7.5.

I can provide a screen recording or additional diagnostic information if needed.

[HuAustin]

Additional data point: I downgraded Loop to version 1.2.0 and tested the same Microsoft Edge-installed PWA on the same Mac running macOS 15.7.5.

With Loop 1.2.0, the issue no longer occurs. Loop’s keyboard shortcuts can move and resize the PWA window normally without causing it to close or crash.

This suggests the behavior may be a regression introduced sometime after 1.2.0. I have confirmed the issue in 1.4.2 (1693) and 1.4.3 (1755), but I have not yet tested every intermediate version to identify the exact release where it was introduced.

[mrkai77]

Quick update after looking further into the upstream Chromium fix: it has landed and is available starting in Chrome Canary 153.0.7978.0, and has also been merged into M151 for stable rollout. The linked Chromium change also clarified the underlying cause; Loop’s synthetic focus event uses all-0xFF coordinates, which are interpreted as NaN values. A Chromium regression caused these values to terminate the Mojo connection, while the new Chromium fix sanitizes them.

AltTab fixed the same invalid event data in version 11.3.1 by replacing those coordinates with a finite CGPoint(x: -1, y: -1) and using a slightly larger event buffer. This is a general improvement that would be worth adding to Loop rather than maintaining a Chromium-specific workaround. @jvanderen1, if you’re willing to update #1132 to replace the existing workaround with the AltTab-style fix, I’d be happy to merge it! Otherwise, we probably won’t be merging the current workaround since Chromium has already fixed the issue upstream.

[jvanderen1]

@mrkai77 Absolutely. I can take a stab at at today or tomorrow. Thanks for working with me on this.

[jvanderen1]

@mrkai77 I went ahead and made those adjustments within #1132. Thanks!