fix(find): re-focus the preview find bar on a repeated Cmd/Ctrl+F - #560
Merged
Conversation
Pressing the shortcut again while the find bar was already open did nothing: the handler only ran `findOpen = true`, which writes the value the state already holds, so the `$effect` that focuses the input never re-ran. After clicking into the document the field could only be reached with the mouse. Focus is now requested explicitly, and the existing `select()` brings the previous query back highlighted so typing replaces it — what Chrome, Firefox and VS Code all do on a repeated find shortcut. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
PathGao
added a commit
that referenced
this pull request
Aug 10, 2026
…spelling (#564) `foldKeys.test.ts` matched markdown.ts for `/h\.id = \w+\.id/` and `removeAttribute("id")`. Both are claims about how the promotion is written, not that it works, and the file already shipped with the two failure modes that come with that: * Extract the four lines into a `promoteAnchorId(h)` helper — same behaviour, every existing test still passing — and the assertion goes red. Measured, not argued. * Nothing in it looked at whether the promoted ids stay unique, which is the whole point of taking the id off the anchor. `processMarkdownHtml` is an exported function in `.ts` and the suite already has a DOM shim (`renderProtocolDom.ts`, used by foldStatePerDocument and five others), so the behaviour can just be run. The document under test now contains the collision the feature exists for — two sections both titled "Setup" — and the check is that collapsing the first leaves the second open. Keyed by text, as it was before the promotion, `new Set(['setup'])` folds the whole document. Deleting the promotion turns both new tests red. The helper-extraction refactor above leaves them green. One source-shape assertion is kept, and says why in place: the preview's `foldableHeader.id || textContent` lives in a Svelte component this runner cannot import, and the keying convention is a contract between producer and consumers rather than an internal call site. Also drops `findRefocus.test.ts` (#560, mine). It pinned `findBar?.focusInput()` — an internal call, free to rename, and green if the focus call stops working. By the criterion in the pull request template it should not have been written. Co-authored-by: PathGao <gaoyanbo@gaoyanbodeMacBook-Air.local> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This was referenced Aug 10, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #559.
The bug
Cmd/Ctrl+Fin preview mode ranfindOpen = trueand nothing else. Once the bar was open that assignment writes the value the state already holds, so the$effectthat focuses the input never re-ran — after clicking into the document, the field could only be reached with the mouse.The fix
FindBarexportsfocusInput()(focus +select(), the code the open-effect already ran), andtriggerFindActioncalls it alongsidefindOpen = true. The open path now delegates to the same function, so there is one implementation rather than two that can drift.The previous query is not cleared, so it comes back selected and typing replaces it — the behaviour the issue asks for, and what Chrome, Firefox and VS Code do on a repeated find shortcut.
close()(Escape / ×) still clears, unchanged.The editor pane is untouched: Monaco's own find widget already re-focuses on a repeated shortcut.
Verification
scripts/findRefocus.test.ts— the shortcut path callsfocusInput,focusInputselects rather than clears, and the focus code exists once.npm run checkclean,npm test944/944 pass.🤖 Generated with Claude Code