[Bug]: Home and End keys do not move the caret in the Ctrl+K search input

[andreashen]

Deployment type

Official App

What happened?

On the Windows desktop app, pressing Ctrl+K opens the search palette as expected. However, when the search input is focused and contains text, pressing Home or End does not move the caret to the beginning or end of the input.

I expected these keys to follow the native Windows text-editing behavior: Home should move the caret to the beginning of the input, and End should move it to the end.

Steps to reproduce

1. Launch the Multica desktop app on Windows.
2. Press Ctrl+K to open the search palette.
3. Type several characters into the search input, for example abcdef.
4. Place the caret somewhere in the middle of the text.
5. Press Home and observe that the caret does not move to the beginning of the input.
6. Press End and observe that the caret does not move to the end of the input.

Screenshots (optional)

No response

Additional context (optional)

Multica desktop version: v0.4.4

[vicksiyi]

Thanks for the report. I opened PR #5695 with a fix: #5695

Root cause: cmdk's root keyboard handler consumes Home/End to select the first/last command item before the focused search input can use native text editing.
Fix: The search input now handles Home/End in capture phase so caret movement stays inside the input while global shortcuts outside text inputs remain unchanged.
Validation: pnpm --filter @multica/views exec vitest run search/search-command.test.tsx passed; pnpm --filter @multica/views lint passed with existing warnings; broader checks were limited by Docker unavailable and unrelated existing test/typecheck failures documented in the PR.

I will keep an eye on CI and review feedback.