Focus goes to wrong window when transient dialog window (Handy overlay) appears/disappears

[zane]

Description

When using Handy (a clipboard manager), its small transient overlay window (172x36px, titled "Recording") appears briefly at the bottom of the screen when holding a hotkey. When this overlay disappears, focus goes to an arbitrary window instead of the previously focused window.

AeroSpace correctly classifies this overlay as a dialog (see AX dump below), but the focus race condition with macOS still results in the wrong window being focused.

Steps to reproduce

1. Have multiple windows on a workspace (e.g. WezTerm, Emacs, Slack, Superhuman)
2. Focus WezTerm
3. Trigger Handy's overlay (hold the configured hotkey)
4. Release the hotkey (overlay dismisses)
5. Focus jumps to a random window (e.g. Superhuman) instead of WezTerm

Environment

• AeroSpace: 0.20.2-Beta
• macOS: 15.7.3 (Build 24G419)
• Handy: 0.8.2

AX dump of the overlay window (3116)

The overlay has:

• No buttons (AXCloseButton, AXFullScreenButton, AXMinimizeButton, AXZoomButton all null)
• AXSubrole: AXDialog
• AXFocused: 0, AXMain: 0
• Aero.AxUiElementWindowType: dialog
• Aero.windowLevel: 25 (not normalWindow)
• Size: 172x36

Full AX dump

{
  "AXActivationPoint": "x:-1.000000 y:957.000000",
  "AXCancelButton": null,
  "AXCloseButton": null,
  "AXDefaultButton": null,
  "AXFocused": 0,
  "AXFrame": "x:649 y:905 w:172 h:36",
  "AXFullScreen": 0,
  "AXFullScreenButton": null,
  "AXMain": 0,
  "AXMinimizeButton": null,
  "AXMinimized": 0,
  "AXModal": 0,
  "AXRole": "AXWindow",
  "AXSubrole": "AXDialog",
  "AXTitle": "Recording",
  "AXZoomButton": null,
  "Aero.AxUiElementWindowType": "dialog",
  "Aero.AxUiElementWindowType_isDialogHeuristic": true,
  "Aero.windowLevel": 25
}

Notes

• The overlay is correctly classified as a dialog by AeroSpace
• The overlay is never focused (AXFocused: 0) and has a non-normal window level (25)
• Despite being a dialog, its appearance/disappearance triggers the macOS focus race condition described in Unreliable focus change when closing windows. Focus race condition with macOS #1097
• The fix from Treat choose GUI fuzzer as a popup and ignore focus changes from all popups #1560 (ignore focus changes from popups) doesn't help here since the overlay is classified as a dialog, not a popup
• Since this window is never focused and has a non-normal window level, AeroSpace could potentially ignore focus events associated with it entirely

Related issues

• Unreliable focus change when closing windows. Focus race condition with macOS #1097 — Focus race condition with macOS
• Focus previous window after closing the child #1086 — Focus previous window after closing child
• Treat choose GUI fuzzer as a popup and ignore focus changes from all popups #1560 — Treat popups and ignore their focus changes
• 0.16.0 causes jumping to another application when Emacs child frame closes #776 — Emacs child frame focus jumping

[github-actions]

Please don't open issues directly, use GitHub Discussions instead. See: #947