Skip to content

Close the palette before running the picked command - #503

Merged
thebhef merged 1 commit into
mainfrom
fix-palette-pick-order
Oct 4, 2026
Merged

thebhef merged 1 commit into
mainfrom
fix-palette-pick-order

Conversation

@thebhef

@thebhef thebhef commented Sep 21, 2026

Copy link
Copy Markdown
Owner

Observation: opening a project from the command palette (owner report,
Windows, 2026-09-21; plans/ungroomed-user-feedback.md item 11) leaves
the mouse pointer invisible — hidden by WebView2 while the palette
input is typed in, and still hidden once the native Open dialog is up.
No app code hides the cursor (git grep for cursor: none / host cursor
calls finds nothing).

Hypothesis: the hidden-pointer state carries into the native dialog
because the dialog opens before the palette has actually left the DOM.
PaletteModal's Enter/click pick handler called onPick directly, and
the command palette's onPick raises handleOpenProject's native
Open dialog synchronously in the same handler that also closes the
palette (setOpenPalette(null)) — so the dialog request goes out
before React (and the webview) has processed the palette's removal
and returned focus.

Fix: PaletteModal now closes first (onClose) and defers the pick
itself by one tick (setTimeout(…, 0)), for both the Enter path and
mouse-click picks, so any native dialog a command raises opens only
after the modal is gone. This is the ordering fix described in the
report; it is unverified on the owner's machine until they try it.

Tests: PaletteModal.dom.test.tsx now runs under fake timers and adds a
case asserting onClose fires before the deferred pick, and that the
pick still runs exactly once.

Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com

This was referenced Sep 21, 2026
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.

1 participant