Skip to content

Fix find highlight and Find Next not advancing (plain text box mode)#11579

Merged
niksedk merged 1 commit into
SubtitleEdit:mainfrom
mjuhasz:fix/find-highlight-plain-textbox
Jun 13, 2026
Merged

Fix find highlight and Find Next not advancing (plain text box mode)#11579
niksedk merged 1 commit into
SubtitleEdit:mainfrom
mjuhasz:fix/find-highlight-plain-textbox

Conversation

@mjuhasz

@mjuhasz mjuhasz commented Jun 13, 2026

Copy link
Copy Markdown
Contributor

Problem

When color tags are disabled (the default plain TextBox mode), two related bugs affected the Find feature:

  1. No highlight — searching with F3 / Find dialog showed the correct subtitle and positioned the caret after the match, but the found text was never highlighted.
  2. Find Next stuck — pressing F3 a second time kept re-finding the same hit instead of advancing to the next occurrence.

Both issues were confined to the plain TextBox path. The AvaloniaEdit path (color tags enabled) was unaffected.

Root cause

Highlight bug (TextBoxWrapper.Select): After setting SelectionStart/SelectionEnd, the method also set CaretIndex = start + length. In Avalonia's TextBox, setting CaretIndex to a new value fires PropertyChanged for CaretIndexProperty, which internally collapses the selection to a zero-length caret — erasing the highlight that was just applied.

Advancement bug (FindNext shortcut): The shortcut read EditTextBox.CaretIndex as the search-start position. With the selection now non-collapsed, CaretIndex reflected SelectionStart (the beginning of the found text), so the next search re-found the same occurrence. The Find dialog already used EditTextBox.SelectionEnd correctly; the shortcut was inconsistent.

Changes

  • TextBoxWrapper.Select() — remove the redundant CaretIndex assignment; SelectionEnd positions the caret automatically.
  • MainViewModel.FindNext() — use EditTextBox.SelectionEnd as the search start, matching the Find dialog path.

In Avalonia's TextBox (used when color tags are disabled), setting
CaretIndex after SelectionStart/SelectionEnd collapses the selection to
a zero-length caret, clearing the find highlight. Remove the redundant
CaretIndex assignment from TextBoxWrapper.Select(); SelectionEnd already
positions the caret.

With a real selection now in place, FindNext shortcut was re-finding the
same hit because it read CaretIndex (= SelectionStart) as the search
start. Switch it to SelectionEnd, matching the Find dialog path.
@niksedk niksedk merged commit 00e7476 into SubtitleEdit:main Jun 13, 2026
2 checks passed
@mjuhasz mjuhasz deleted the fix/find-highlight-plain-textbox branch June 13, 2026 19:46
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.

2 participants