fix(macOS): recompute find match ranges before Replace#251
Draft
cursor[bot] wants to merge 1 commit into
Draft
Conversation
replaceCurrentMatch used lastSearchHighlightRanges from the last applySearchHighlights pass. Any edit while the find bar stays open left those UTF-16 ranges stale, so Replace could corrupt the note or hit an invalid storage range. Re-scan the live string (same rules as the find UI) before replacing, and align nextMatchIndex with the needle-based scan used for highlighting. Co-authored-by: Danny Peck <dannypeck@gmail.com>
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.
Bug and impact
Replace / Replace & Find in the note editor used cached
lastSearchHighlightRangesfrom the last highlight pass. If the user edited the note while the find bar stayed open, those UTF-16 ranges could point at the wrong substring or past the end of the storage. That could corrupt note content (wrong text replaced) or cause runtime failures when applying the replacement.Root cause
replaceCurrentMatchreadlastSearchHighlightRanges[focusIndex]without re-scanningtextStorage.string. Highlights are only refreshed on find-bar-driven events, not on every keystroke, so the cache could go stale.Fix
applySearchHighlights.nextMatchIndexwith that same scan so the post-replace focus index stays consistent with the find UI.Validation
xcodebuildtests are not available in this Linux agent environment; change is localized toLinkAwareTextViewsearch/replace helpers inEditorView.swiftand follows the existing highlight matching logic.