Under the settings redesign, starting a new search before the previous
one finished produced inconsistent highlight results on Windows and
Linux. searchFunction awaits at several points, so a stale call could
resume after a newer search and re-add find-selection ranges, tooltips,
and menuitem indicators. The code checked for this at only two of those
points, using a narrow `query !== this.query` comparison.
A stale call must not mutate shared state after a newer search starts.
Each search aborts the previous one on entry, then after each await
checks whether a newer search has aborted it. When a stale call resumes
and sees the abort, it returns early. The subQuery fast path checks a
new searchCompleted flag. After an unfinished search, `.visually-hidden`
may be partly applied, so the next search runs in full instead of
incrementally. The awaits in `searchWithinNode` need the same fix, left
for a follow-up.
Two SRD-only regression tests cover this by asserting the SELECTION_FIND
range count does not inflate when searches overlap. One drives the
overlap directly through searchFunction. The other reproduces it through
the real search input, matching the reported interaction.
Differential Revision: https://phabricator.services.mozilla.com/D309716
Tim Giles
2bcce9ebe0