Describe the bug
CommandPalette updates its active result on mouseenter. This means a stationary mouse cursor can override the expected keyboard-first selection when the palette opens or when the search results change.
If the cursor happens to be positioned over a result row after the palette renders, that row becomes selected even though the user has not moved the mouse and is interacting via keyboard. Pressing Enter then selects the hovered row instead of the first/top-ranked result.
Reproduction
- Render
CommandPalette with several items.
- Leave the mouse cursor around the area where the result list will appear.
- Open the palette with the keyboard shortcut.
- Type a query that returns multiple results.
- If the stationary cursor is over the third result, that result becomes active.
- Press
Enter.
Expected behavior
When the user opens the command palette and types from the keyboard, the first matching result should remain selected unless the user actively navigates with arrow keys or actually moves/clicks the mouse.
Current behavior
A result under the stationary cursor can become selected through mouseenter, so keyboard Enter may activate a non-first result.
Relevant code
In CommandPalette.svelte, list items currently do this:
onmouseenter={() => (selectedIndex = index)}
selectedIndex is private, so consumers cannot reliably reset or control this from outside.
Suggested fix
Consider using pointer/mouse movement rather than mouseenter for changing the active item, for example pointermove / mousemove, so a stationary cursor does not steal selection. It may also help to reset selectedIndex to 0 when the search query or filtered result set changes.
The key behavior would be:
- Keyboard typing keeps the first matching result selected.
- Arrow keys still change selection.
- Mouse movement still changes selection.
- Mouse click still selects the clicked item.
Version
Observed with flowbite-svelte@1.33.1.
Additional context
This is most visible when command results are sorted by recency/frequency/score: the top result is intentionally the best match, but a stationary mouse cursor can cause Enter to activate a lower-ranked row.
Describe the bug
CommandPaletteupdates its active result onmouseenter. This means a stationary mouse cursor can override the expected keyboard-first selection when the palette opens or when the search results change.If the cursor happens to be positioned over a result row after the palette renders, that row becomes selected even though the user has not moved the mouse and is interacting via keyboard. Pressing
Enterthen selects the hovered row instead of the first/top-ranked result.Reproduction
CommandPalettewith several items.Enter.Expected behavior
When the user opens the command palette and types from the keyboard, the first matching result should remain selected unless the user actively navigates with arrow keys or actually moves/clicks the mouse.
Current behavior
A result under the stationary cursor can become selected through
mouseenter, so keyboardEntermay activate a non-first result.Relevant code
In
CommandPalette.svelte, list items currently do this:onmouseenter={() => (selectedIndex = index)}selectedIndexis private, so consumers cannot reliably reset or control this from outside.Suggested fix
Consider using pointer/mouse movement rather than
mouseenterfor changing the active item, for examplepointermove/mousemove, so a stationary cursor does not steal selection. It may also help to resetselectedIndexto0when the search query or filtered result set changes.The key behavior would be:
Version
Observed with
flowbite-svelte@1.33.1.Additional context
This is most visible when command results are sorted by recency/frequency/score: the top result is intentionally the best match, but a stationary mouse cursor can cause
Enterto activate a lower-ranked row.