Page MenuHomePhabricator

Wikipedia editor does not remember position of the cursor but resets it to the beginning
Closed, InvalidPublic

Description

This behaviour has started several weeks (maybe months) ago. Before something changed, blinking cursor position used to be remembered so that after Previewing some page and scrolling down to the editor – cursor was where it was left, so continuation of editing was easier. Now cursor gets reset to beginning after previewing some page. Can this be fixed or is intentional behaviour?

Steps to reproduce the problem:

  1. Go to some longer article at any Wikipedia, e.g. https://en.wikipedia.org/wiki/Mathematical_object, with Google Chrome or Mozilla Firefox or IE 11 (latest version)
  2. Log out of Wikipedia (preferably also close all browser windows, then reopen the browser and fresh-open the article again; not necessary), and then after that click on "Edit" tab to edit Wikipedia article allowed for editing as IP address
  3. After Welcome message is shown click "Start editing" button (to get normal wikieditor, not Visual one), and then scroll down in wikieditor to see "See also" text (to see it in the editor itself)
  4. Clear e.g. "a" in "See also" to get "See lso" with blinking cursor left to the letter "l" and right to the space, and then click Show preview (do not click Save changes)
  5. After preview is fully loaded, scroll the page to the wikieditor without clicking anything (except page scrollbar, if mouse or device has no scroll)

Expected result: Blinking cursor is where it has been left, between space and letter "l", with wikieditor scroll positioned as it has been left – or in a such way that blinking cursor can be seen in a position it has been left.

Actual result: There is no blinking cursor at all, text in wikieditor is deselected and wikieditor scroll got reset to beginning (top) – what makes continuation of editing harder (especially if article is really long) because user who is editing must find word(s) where he stopped if he wants to continue from that particular point/part (in this case to continue with editing text "See lso" to correct it).

Few month ago, Actual result was Expected result, as given above; now actual result is as given above because scroll gets reset to beginning and does not remember its position.

Event Timeline

Obsuser created this task.Aug 18 2017, 7:19 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 18 2017, 7:19 AM
Aklapper changed the task status from Open to Stalled.Aug 18 2017, 10:23 AM
Aklapper removed a project: Wikimedia-Site-requests.

Hi @Obsuser, thanks for taking the time to report this!
Unfortunately this report lacks some information. If you have time and can still reproduce the problem: Please add a more complete description to this report (a list of steps to reproduce which leave no room for interpretation what to do, describing actual results and expected results after performing the steps to reproduce, attaching or linking to a public testcase, browser information and browser version information, MediaWiki version information, whether you use the classic wikitext editor or the VisualEditor, etc). You can edit the task description by clicking Edit Task.
Ideally, exact and clear steps to reproduce should allow any other person to follow these steps (without having to interpret those steps) and see the same results. Problems that others can reliably reproduce can get fixed faster. Thanks!

[ removing Wikimedia-Site-requests as this is not about site configuration ]

Obsuser updated the task description. (Show Details)Aug 19 2017, 7:32 AM
Obsuser updated the task description. (Show Details)Aug 19 2017, 7:36 AM
Aklapper changed the task status from Stalled to Open.Aug 22 2017, 8:15 AM
Jdforrester-WMF closed this task as Invalid.Aug 24 2017, 7:11 PM
Jdforrester-WMF added a subscriber: Jdforrester-WMF.

I'm pretty sure that the expected result hasn't ever been the case. In fact, I don't know how it would work for the workflow described; pressing the preview button means moving to a new page (that looks the same to a human), and the browser won't know that the textarea on the new page is a replacement for the one on the previous page.

I think you're instead thinking of the workflow with the on-page previews feature (previously called "live previews", now labelled "Show previews without reloading the page") switched on, which sounds very similar but doesn't reload the page; I've tested that, and that still leaves the textarea scrolled to the place it was before you clicked preview.

Provisionally closing as Invalid.

Thank you, you're most probably right; I just don't know whether that automatically got turned off at some point, and where is it located to turn it on again (because it makes editing a bit faster)?