Page MenuHomePhabricator

Cannot scroll to top of page in VE with template or image selected
Open, Needs TriagePublicBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

What happens?:
As soon as you scroll all the way to the top, the window jumps back down to make the selected template or image visible again.

What should have happened instead?:
It should just stay to wherever you scrolled to.

Software version (on Special:Version page; skip for WMF-hosted wikis like Wikipedia):

  • MacOS Sonoma 14.5
  • Can repro on either of:
    • Chrome Version 137.0.7151.122 (Official Build) (arm64)
    • Firefox 137.0.2 (aarch64)

I can repro when logged in to my account or an incognito window on Chrome, or while logged out in Firefox.

Event Timeline

There are further reports in de.Wikipedia here:
https://de.wikipedia.org/wiki/Wikipedia:Fragen_zur_Wikipedia#Im_Visual_Editor_kann_man_oft_nicht_mehr_an_den_Artikelanfang_scrollen

The problem also appears when the cursor is placed on a wikilink, so that the "box for wikilinks" opens. I tested this with different skins: all skins are affected by the problem.

@Esanders Could this problem be caused by changes to https://github.com/wikimedia/mediawiki-extensions-VisualEditor/blob/master/editcheck/modules/controller.js ?

It's not anything to do with the edit check controller -- it's a side-effect of Surface padding: Refactor so that surface calculates own padding.

So, the issue is:

  1. You select anything that has a context item. Doesn't have to be a block like a template/image, a link works just as well.
  2. You scroll to the top of the page, to the point where the toolbar unfloats. (Or, technically, do other things that trigger a position event. This is simple to make happen, though.)
  3. The context (which is the container for the context item) decides that it needs to update its dimensions.
  4. As part of this it uncritically emits a "I've changed size" event.
  5. The editing surface notices this, and decides that it needs to scroll the selected thing back into view.

Fix is either to tell the context that it doesn't need to update dimensions for this kind of event, to pass the knowledge that this isn't the kind of thing that needs the scroll position updated down to where the scrolling is happening, or have the resize event only get emitted if there was an actual change.

Change #1170653 had a related patch set uploaded (by DLynch; author: DLynch):

[VisualEditor/VisualEditor@master] DesktopContext: don't update dimensions on passive position events

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

I notice that one of the people in the linked talk page said "Now I know it's not my mobile device". If it's happening on mobile, that would be via a different route than is addressed on this patch. (Probably via it reacting to the browser location bar showing/hiding when you scroll causing a page-resize.)

Change #1170653 merged by jenkins-bot:

[VisualEditor/VisualEditor@master] DesktopContext: don't update dimensions on passive position events

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

Change #1172469 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (810cd4b38)

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

Change #1172469 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (810cd4b38)

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

Tested on mobile and desktop screens, desktop works fine. Mobile remains jumpy when editing full page; seems to work when editing individual sections.

If we need a different route for the mobile fix, do we need to track that in a different ticket?

I notice that one of the people in the linked talk page said "Now I know it's not my mobile device". If it's happening on mobile, that would be via a different route than is addressed on this patch. (Probably via it reacting to the browser location bar showing/hiding when you scroll causing a page-resize.)

Change #1179019 had a related patch set uploaded (by DLynch; author: DLynch):

[VisualEditor/VisualEditor@master] Only scroll to selection on position events if the selection was visible

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

ppelberg moved this task from QA to Code Review on the Editing-team (Kanban Board) board.
ppelberg subscribed.

This will be ready again for QA once the patch that – I assume – David Lynch wrote [i] to address the issue Esther described in T398777#11041751.


i. https://gerrit.wikimedia.org/r/1179019 is reviewed

Change #1237351 had a related patch set uploaded (by DLynch; author: DLynch):

[VisualEditor/VisualEditor@master] ui.Surface: don't automatically scroll in adjustVisiblePadding

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

Change #1179019 abandoned by DLynch:

[VisualEditor/VisualEditor@master] Only scroll to selection on position events if the selection was visible

Reason:

Too complicated

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

Change #1237351 merged by jenkins-bot:

[VisualEditor/VisualEditor@master] ui.Surface: don't automatically scroll in adjustVisiblePadding

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

Change #1237970 had a related patch set uploaded (by Esanders; author: Esanders):

[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (b1b8c784c)

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

Change #1237970 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (b1b8c784c)

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

Merged patch should, at least, significantly reduce incidences of the selection causing you to get scrolled. There'll still be ways to make it happen (e.g. closing the inspector for the node you have selected will jump you back to it), but just scrolling the page around shouldn't do it any more.