Change 815351 had a related patch set uploaded (by MusikAnimal; author: MusikAnimal):

[mediawiki/extensions/WikiEditor@master] Realtime Preview: preserve caret position when opening/closing RTP

https://gerrit.wikimedia.org/r/815351

@MusikAnimal https://gerrit.wikimedia.org/r/815351 preserves the caret on the selected position for me, but the scrolling position changes. For instance, if I first place the caret at the beginning of a word in the middle of a page and I open the preview the scrolling position changes on the left (expected) since the pane becomes narrower but when I close realtime preview the word where I placed the caret is not in the middle of the page. The caret is at the right place but the scroll position is not preserved. This only happens on the first open and close of realtime preview.

Does my explanation make sense?

Change 815351 merged by jenkins-bot:

[mediawiki/extensions/WikiEditor@master] Realtime Preview: preserve caret position when opening/closing RTP

https://gerrit.wikimedia.org/r/815351

In T311684#8089713, @HMonroy wrote:

@MusikAnimal https://gerrit.wikimedia.org/r/815351 preserves the caret on the selected position for me, but the scrolling position changes. For instance, if I first place the caret at the beginning of a word in the middle of a page and I open the preview the scrolling position changes on the left (expected) since the pane becomes narrower but when I close realtime preview the word where I placed the caret is not in the middle of the page. The caret is at the right place but the scroll position is not preserved. This only happens on the first open and close of realtime preview.

Does my explanation make sense?

Yes it makes sense! I'm not sure how to fix it though. I actually can't reproduce it the way you describe. For me the scroll position is lost only when opening RTP. I tested on Firefox in Vector 2022.

At any rate, while this task does say "Preserve scroll position", I feel like the caret position is the more important part. Speaking for myself, I'm able to find where I am in the editing pane because it has focus and the cursor is blinking, and I'm able to type in the same place I was, etc.

@NRodriguez Any input on what the right behaviour should be? The above patch has been merged and should now be on the Beta cluster if you'd like to try it out.

Tried it out in Beta! It works as I would expect it. I think also maybe a distinction @dom_walden may have meant to make but it can get confusing to think about scroll versus caret! Def agree caret is the more specific marker

Thanks! Moving to QA, then.

One thing I am finding on Chrome is that if I highlight text and open/close RTP, you are returned to the top of the editing pane rather than the position of the highlighted text.

This also affects linter highlighting (e.g. https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Diabetes_in_dogs&action=edit&lintid=494), where it is not scrolled to the highlighted position when you open the page. This also happens with RTP disabled, so perhaps it is a preexisting bug. It does sound similar to an old bug (T152760) which was apparently fixed but might not be anymore.

Without anything highlighted, it returns to the caret position.

@HMonroy @MusikAnimal can you reproduce this? I tested it on Chrome 103.

EDIT: Interestingly, I think it works with CodeMirror on.

Also, I don't think it returns to the caret position on Safari 15 when opening/closing RTP.

In T311684#8097126, @dom_walden wrote:

One thing I am finding on Chrome is that if I highlight text and open/close RTP, you are returned to the top of the editing pane rather than the position of the highlighted text.

It took a few tries but I was able to reproduce. Thanks for pointing out T152760! That provides a solution that seems to work wonderfully here. Patch incoming!

Change 816877 had a related patch set uploaded (by MusikAnimal; author: MusikAnimal):

[mediawiki/extensions/WikiEditor@master] Realtime Preview: scroll to cursor when opening/closing RTP

https://gerrit.wikimedia.org/r/816877

Change 816877 merged by jenkins-bot:

[mediawiki/extensions/WikiEditor@master] Realtime Preview: scroll to cursor when opening/closing RTP

https://gerrit.wikimedia.org/r/816877

Back to QA. We're now using jQuery.textSelection's scrollToCaretPosition, so the experience should be consistent across browsers. I am not able to test on Safari, though.

So, in general, when opening or closing the Preview the editing pane is scrolled such that the caret appears at the bottom of the editing pane. Or, so the end of the highlighted section is at the bottom of the editing pane.

There are some exceptions and inconsistencies, but I don't think any would block a release. @NRodriguez let me know if you would like any of these raised as separate bugs:

1. On Chrome, if the initial state of RTP is closed or the feature is disabled, opening an edit session with linter highlighting does not scroll the highlighting into view. Instead, it takes you to the top of the page. This is with or without CodeMirror. This may be a preexisting bug (e.g. T152760).
   
2. When first opening an edit session with linter highlighting and CodeMirror enabled, the scroll position is slightly off (by a few lines). This also happens with RTP closed or disabled. You also see when you first open CodeMirror that the scroll position slightly changes. It may be a preexisting bug.
   
3. With CodeMirror enabled, opening and closing RTP can lead to inconsistencies in whether the caret/highlight position is at the top of the editing pane or at the bottom. This varies depending on browser and where you were scrolled (above or below the current caret/highlight position) when you opened/closed RTP.
4. On Firefox, with RTP initially open, CodeMirror off and no highlighting, if you soft refresh you are sometimes scrolled all the way to the bottom of the page. I am not exactly sure how to reproduce this reliably.
5. On Firefox, with RTP initially open, CodeMirror on and no highlighting, soft refresh sometimes scrolls you to the bottom of the page and sometimes to the position you were scrolled (not the caret position).