It seems to force the scroll to where you last placed the text cursor, and only when this is below the string being replaced. Affects at least the English and French Wikipedias and Commons.

This is a very annoying bug.

Steps to Reproduce:

1. Edit any wiki page.
2. Make sure it has enough text to make a scrollbar appear. If not, add more text until it does. Here's my example:
   • 
3. Press Ctrl+F, and search for a string that has matches in the general top region of the page.
4. Focus the find & replace tool on one of these topmost matches (i.e., use the clickable arrow buttons to navigate to one, so it is darker green).
5. Scroll down the page, and click anywhere in the text to place the text cursor.
6. (Optional) Scroll back up (any distance).
7. Click "Replace".

Actual Results:

The string in dark green is replaced, but the editor scrolls back down to where you last placed the cursor (after about 500ms). It's a similar bug to T228251, which has yet to be fixed (by the VisualEditor team or Chrome), but this one occurs in Firefox too (I tested). That post makes clear that it's not a Chrome bug, because the VisualEditor behaviour is not necessary and did not occur prior to 2019, despite the continued presence of the reported Chrome behaviour dating back to 2014 (tested).

Expected Results:

The string in dark green is replaced, and the scroll position does not change.