Sometimes also with syntax highlighting off, also when editing only a section

Which specific web browsers and web browser versions has this been seen with?

I'll ask reporters. I reproduced it with syntax highlighting on using Firefox 64 (Linux 64bit).

One of reporters: both Firefox 60.4.0esr, or Chromium 71.0.3578.98 (Linux 64bit)

Second reporter: Google Chrome 71.0.3578.98 (64bit)

So the reason this is more 'weird' with CodeMirror, is that the edit window should be setting the scroll offset of the textarea to the offset of the previous page (this is intentional WikiEditor behavior). But the scroll offset of the wikieditor (aka wpTextbox1) and the CodeMirror surface are not synchronized. As such when CodeMirror is enabled, it always sets the scroll position to 0 of the textbox when you preview (instead of to the actual previous scrolloffset in codemirror).

aka CodeMirror does not have the mediawiki.action.edit equivalent of, which due to lack of synchronisation currently will always be set to 0

$editForm.on( 'submit', function () {
     scrollTop.value = editBox.scrollTop;
} );

@MusikAnimal I see your commit message from 314bd6d8c4a8b987be627d60ec6e62be811726c4. Could you explain it a little bit more? Scrolling selection into view is not the expected behavior with the native textarea. Maybe we only need to let this.view.scrollDOM, instead of the page, scroll to the selection?

In T212899#9481755, @Bhsd wrote:

@MusikAnimal I see your commit message from 314bd6d8c4a8b987be627d60ec6e62be811726c4. Could you explain it a little bit more? Scrolling selection into view is not the expected behavior with the native textarea. Maybe we only need to let this.view.scrollDOM, instead of the page, scroll to the selection?

This task seems to be about the native textarea. The commit you linked to only effects CodeMirror 6 + WikiEditor, and also only when a selection was already made on the native textarea. This fixes a longstanding issue with CodeMirror.

For example, compare:

• https://en.wikipedia.org/w/index.php?title=User_talk:Patmax23&action=edit&lintid=2705052 (jumps to the top)
• https://en.wikipedia.org/w/index.php?title=User_talk:Patmax23&action=edit&lintid=2705052&cm6enable=1 (correctly shows the selected text)

That said, I'm not able to reproduce the bug reported here on my local, both with and without CodeMirror. With "Show preview without reloading the page" disabled and "Show preview before edit box" enabled, it seems to always jumps to the top of the page in my testing.

In T212899#9482293, @MusikAnimal wrote:

• https://en.wikipedia.org/w/index.php?title=User_talk:Patmax23&action=edit&lintid=2705052 (jumps to the top)
• https://en.wikipedia.org/w/index.php?title=User_talk:Patmax23&action=edit&lintid=2705052&cm6enable=1 (correctly shows the selected text)

Testing this with CM turned off, I see it still jumps to the top. That's probably an issue with WikiEditor, then. But that's still not the same issue being reported in this task, apparently (?) which says "Change something, click on the preview button" – meaning there would be no preselected text on page reload.

You are right. This ticket is not about selection, but the scrollIntoView: true option will always scroll the preview page down to the editor. I am not sure whether you manually modified the editform's action property in order to preserve cm6enable=1 after the page reloads.

I think there are at least 2 separate aspects being discussed/confused here, and I think at least one of the recently merged tasks was not a duplicate.

The 2 aspects are the the scroll-locations of:
A. the entire window/web-page
B. the wikitext edit-area

The most common existing and historical possible outcomes upon clicking "Show preview" are:

1. Window is scrolled to top, and Edit-area is scrolled to top.
   • This is the generic default. We currently get this if CodeMirror is disabled.
2. Window is scrolled to just-above the Edit-area, and the Edit-area is scrolled to top.
   • We currently get this if CodeMirror is enabled.
3. Window is scrolled to top, and Edit-area is scrolled to where it was previously scrolled-to.
   • We used to have this very helpful behaviour, and that's what T254962 is about (and should be re-opened, unless the patch mentioned here will fix it?)
   • It enables someone to not have to scroll down to where they were editing after a preview, which means we don't lose our momentum, especially for editors who are doing a complex edit that involves multiple previews before saving.
   • This behaviour still works if I turn off "Enable the editing toolbar" in my preferences.

Thus, if I understand correctly, the many tasks are saying:

• Most of us currently get Option 1 or 2.
• Option 1 is acceptable, but Option 3 is preferred.
• Option 2 should not happen (but has been for years, for anyone that uses CodeMirror)

I made a quick screencast of the 3 behaviors (too big for attaching here, so I put it at https://youtu.be/Wsdwzn2GD4s ) in case that helps.

In T212899#9482819, @Quiddity wrote:

I think there are at least 2 separate aspects being discussed/confused here, and I think at least one of the recently merged tasks was not a duplicate.

Indeed there are two visible differences in the scrolling behavior during preview between CodeMirror and the native textarea, but it looks to me that these two differences are caused by the same reason and can be resolved in a same solution.

Change 1005403 had a related patch set uploaded (by Bhsd; author: Bhsd):

[mediawiki/extensions/CodeMirror@master] fix scroll behavior of CodeMirror 6

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

Change 1005403 merged by jenkins-bot:

[mediawiki/extensions/CodeMirror@master] fix scroll behavior of CodeMirror 6

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