Skip to content

fix: source-selector window crash blocking all recording - #8

Merged
Alfredoalv13 merged 1 commit into
mainfrom
fix/source-selector-hud-provider-crash
Jul 20, 2026
Merged

fix: source-selector window crash blocking all recording#8
Alfredoalv13 merged 1 commit into
mainfrom
fix/source-selector-hud-provider-crash

Conversation

@Alfredoalv13

Copy link
Copy Markdown
Owner

Summary

  • The standalone source-selector BrowserWindow (opened via openSourceSelector() when starting a new recording) has crashed on every load since May 7, before any of the recent MVP review work.
  • Root cause: SourceSelector and the popovers it renders call useHudInteraction(), which throws if there's no HudInteractionContext.Provider ancestor. That provider only ever existed inside LaunchWindow (the HUD overlay), never around the standalone source-selector window rendered by App.tsx's case "source-selector".
  • User-visible symptom: after granting permissions and clicking Record, the source-selector window opens completely blank (no source list, no camera preview), and recording never starts.
  • Fix: wrap that one case in App.tsx with a local HudInteractionContext.Provider supplying no-op handlers. The real handlers exist to keep the transparent, click-through HUD overlay from ignoring mouse input while a popover is open - the standalone source-selector window isn't transparent/click-through, so a no-op is the semantically correct fix, not wiring up the HUD-specific drag state this window doesn't have.

Test plan

  • tsc --noEmit clean
  • npm test - 94/94 files, 817/817 tests passing
  • Manual: click Record, confirm the source-selector window shows the source list and camera preview, and recording actually starts

SourceSelector (and the popovers it renders) calls useHudInteraction(),
which throws outside a provider. That's fine when SourceSelector is
nested inside LaunchWindow's HUD overlay, but the app also opens it as
its own standalone BrowserWindow (windowType=source-selector) via
openSourceSelector() when starting a new recording, with no provider
in scope there - so that window has crashed on every load since this
hook was introduced in May, well before any of our recent work. Users
saw a blank window with no source list and no camera preview, and
recording never actually started.

The standalone window isn't the transparent click-through HUD overlay,
so the passthrough coordination the real handlers perform doesn't
apply here - a local no-op provider is the correct fix, not wiring up
the HUD-specific drag/pointer state this window doesn't have.
@Alfredoalv13
Alfredoalv13 merged commit c54503b into main Jul 20, 2026
1 check passed
@Alfredoalv13
Alfredoalv13 deleted the fix/source-selector-hud-provider-crash branch July 20, 2026 16:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants