Symptom
After running for a while, the switcher stops rendering: pressing the trigger shows no icons. Switching still works — a quick press-and-release swaps between the last two apps — so the keystroke is being handled somewhere, just not by a visible panel.
Quitting and relaunching SpaceTab restores normal behaviour for a while.
Ruled out
From a Copy Diagnostics capture taken while the fault was active:
trigger: Cmd+Tab
blur: true
tap healthy: true
accessibility: true
passing through:false
screens: 1
panel visible: false onScreen: false frame: (569.0, 400.0, 572.0, 190.0)
apps cached: 4
The ring buffer contained no failure entries at all, which eliminates every instrumented guard:
- not an empty app list from
WindowEnumerator
- not a panel stranded on coordinates without a live screen
- not a disabled event tap (
tap healthy: true)
- not a missing Accessibility grant
- not the pass-through list matching the frontmost app
A window-server probe during the fault confirmed the panel was correctly sized and positioned (572x190 at 569,416 on the only display, layer 101, alpha 1) but never became on-screen.
Remaining hypotheses
- The trigger never reaches the tap callback — a tap that reports healthy but no longer receives events, or something consuming the chord ahead of it.
- The panel is ordered front but not composited — hidden behind another window, or not drawn.
Next capture
Instrumentation added in 604c05d distinguishes the two: every trigger is logged before any guard runs, and present() reports occlusionState shortly after ordering front.
When it recurs, either use Copy Diagnostics from the menu, or retrieve persisted anomalies after the fact:
log show --predicate 'subsystem == "com.mp.spacetab"' --last 1h --style compact
Note that routine events are in-memory only (e80ca86), so Copy Diagnostics before relaunching is the richer capture.
Mitigation already shipped
0fc7bb6 makes the tap consume the trigger only when the switcher is actually shown, so this now degrades to the stock macOS switcher instead of a dead key that does nothing.
Symptom
After running for a while, the switcher stops rendering: pressing the trigger shows no icons. Switching still works — a quick press-and-release swaps between the last two apps — so the keystroke is being handled somewhere, just not by a visible panel.
Quitting and relaunching SpaceTab restores normal behaviour for a while.
Ruled out
From a
Copy Diagnosticscapture taken while the fault was active:The ring buffer contained no failure entries at all, which eliminates every instrumented guard:
WindowEnumeratortap healthy: true)A window-server probe during the fault confirmed the panel was correctly sized and positioned (572x190 at 569,416 on the only display, layer 101, alpha 1) but never became on-screen.
Remaining hypotheses
Next capture
Instrumentation added in 604c05d distinguishes the two: every trigger is logged before any guard runs, and
present()reportsocclusionStateshortly after ordering front.When it recurs, either use Copy Diagnostics from the menu, or retrieve persisted anomalies after the fact:
log show --predicate 'subsystem == "com.mp.spacetab"' --last 1h --style compactNote that routine events are in-memory only (e80ca86), so
Copy Diagnosticsbefore relaunching is the richer capture.Mitigation already shipped
0fc7bb6 makes the tap consume the trigger only when the switcher is actually shown, so this now degrades to the stock macOS switcher instead of a dead key that does nothing.