Page MenuHomePhabricator
Create Task
Maniphest T194122

Cursor position sometimes gets lost when switching from temporary wikitext editor to final editor
Open, Needs TriagePublic
Actions

Description

Steps to reproduce:

  1. Open a page for editing in NWE.
  2. Place the cursor somewhere in the page, while it is still loading.
  3. Optionally: Type one letter.
  4. Wait until the final editor is loaded.

Expected:
The cursor stays in the same place, your edit from step 3 is kept.

Actual:
Sometimes, the cursor is instead reset to the start of the article. When you typed one letter, that letter may be lost, but instead the cursor advances by one place, i.e. is placed after the first letter.

I'm not able to reliably reproduce the issue, especially since the editor loads so fast for me that most of the time it is hard to execute all the above steps while the temporary editor is still in use.

Event Timeline

Schnark created this task.May 8 2018, 7:39 AM
Restricted Application added a project: VisualEditor. · View Herald TranscriptMay 8 2018, 7:39 AM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Esanders subscribed.May 8 2018, 12:00 PM

Do you have syntax highlight enabled?

Esanders added a comment.May 8 2018, 12:04 PM

I can't see a mechanism for it happening without syntax highlighting, as as soon as we read out the content and the last selection, we disable the textarea.

• Deskana changed the task status from Open to Stalled.May 8 2018, 6:42 PM
• Deskana subscribed.

Stalled pending more instructions on how to reproduce.

Schnark added a comment.May 9 2018, 6:50 AM
In T194122#4190081, @Esanders wrote:

Do you have syntax highlight enabled?

It happens both with and without syntax highlight, so unless CodeMirror does something even when present only disabled, it doesn't have anything to do with it.

Schnark added a comment.May 9 2018, 9:57 AM

The best way to avoid this bug seems to be to try to reproduce it ...

I think it is something that happens after https://gerrit.wikimedia.org/g/mediawiki/extensions/VisualEditor/+/master/modules/ve-mw/init/targets/ve.init.mw.DesktopArticleTarget.init.js#147, but before https://gerrit.wikimedia.org/g/mediawiki/extensions/VisualEditor/+/master/modules/ve-mw/init/targets/ve.init.mw.DesktopArticleTarget.js#469. It's obvious that any cursor change between these two points will be ignored, but I have no idea how much time there is between them.

I also have "search as you type" enabled in Firefox, so when I type something while the temporary editor is read-only, this will invoke the search, and so moves the focus. So this setting might have something to do with this issue.

Ryasmeen changed the task status from Stalled to Open.EditedMay 9 2018, 4:45 PM
Ryasmeen subscribed.

Yup, it is reproducible following the steps mentioned in the report when I have syntax highlighting on. But yeah, I had to do it super fast to make it happen :)
Also after that point the cursor starts acting completely weird. Here is a video capture to show what happens:

cursoring.mov.zip3 MBDownload

Esanders added a comment.May 10 2018, 3:27 PM

@Ryasmeen In your video you don't appear to be using the temporary wikitext editor (the one that shows before the toolbar is ready), and also syntax highlighting is enabled, so that would appears to be a separate bug (probably with SyntaxHighlighting).

Esanders added a comment.EditedMay 10 2018, 3:29 PM
In T194122#4193443, @Schnark wrote:

The best way to avoid this bug seems to be to try to reproduce it ...

I think it is something that happens after https://gerrit.wikimedia.org/g/mediawiki/extensions/VisualEditor/+/master/modules/ve-mw/init/targets/ve.init.mw.DesktopArticleTarget.init.js#147, but before https://gerrit.wikimedia.org/g/mediawiki/extensions/VisualEditor/+/master/modules/ve-mw/init/targets/ve.init.mw.DesktopArticleTarget.js#469. It's obvious that any cursor change between these two points will be ignored, but I have no idea how much time there is between them.

I also have "search as you type" enabled in Firefox, so when I type something while the temporary editor is read-only, this will invoke the search, and so moves the focus. So this setting might have something to do with this issue.

In the first call you link to we do tempWikitextEditor.$element.prop( 'readonly', true ); which means no more input is allowed. (I note that in Firefox you can still move the cursor, but that would manifest as a different issue).

It's possible the user is able to type into the real surface before the data from the temp surface is written to it.... No, we write the data directly into the API response object.

Schnark added a comment.May 11 2018, 7:39 AM
In T194122#4197528, @Esanders wrote:
In T194122#4193443, @Schnark wrote:

The best way to avoid this bug seems to be to try to reproduce it ...

I think it is something that happens after https://gerrit.wikimedia.org/g/mediawiki/extensions/VisualEditor/+/master/modules/ve-mw/init/targets/ve.init.mw.DesktopArticleTarget.init.js#147, but before https://gerrit.wikimedia.org/g/mediawiki/extensions/VisualEditor/+/master/modules/ve-mw/init/targets/ve.init.mw.DesktopArticleTarget.js#469. It's obvious that any cursor change between these two points will be ignored, but I have no idea how much time there is between them.

I also have "search as you type" enabled in Firefox, so when I type something while the temporary editor is read-only, this will invoke the search, and so moves the focus. So this setting might have something to do with this issue.

In the first call you link to we do tempWikitextEditor.$element.prop( 'readonly', true ); which means no more input is allowed. (I note that in Firefox you can still move the cursor, but that would manifest as a different issue).

The fact Firefox allows moving the cursor in a readonly textarea does explain this issue:

  • The temporary editor loads, with the cursor at the start of the text.
  • syncTempWikitextEditor is called, the cursor position (= 0) is stored, the textarea is set readonly.
  • I put the cursor somewhere (which I can, because the textarea is just readonly and not disabled).
  • afterActivate is called, and sets the cursor to the stored position, i.e. resets to the start of the text
• Vvjjkkii renamed this task from Cursor position sometimes gets lost when switching from temporary wikitext editor to final editor to 1edaaaaaaa.Jul 1 2018, 1:11 AM
• Vvjjkkii triaged this task as High priority.
• Vvjjkkii added projects: CheckUser, Connected-Open-Heritage-Batch-uploads (RAÄ-KMB_1_2017-02), Tamil-Sites, Gamepress, Hashtags, Jade, KartoEditor, Language-2018-Apr-June, New-Editor-Experiences, Mail, TCB-Team (now WMDE-TechWish).
• Vvjjkkii updated the task description. (Show Details)
• Vvjjkkii removed a subscriber: Aklapper.
CommunityTechBot raised the priority of this task from High to Needs Triage.Jul 1 2018, 3:45 PM
CommunityTechBot updated the task description. (Show Details)
CommunityTechBot removed projects: TCB-Team (now WMDE-TechWish), Mail, New-Editor-Experiences, Language-2018-Apr-June, KartoEditor, Jade, Hashtags, Gamepress, Tamil-Sites, Connected-Open-Heritage-Batch-uploads (RAÄ-KMB_1_2017-02), CheckUser.
CommunityTechBot added a subscriber: Aklapper.
CommunityTechBot renamed this task from 1edaaaaaaa to Cursor position sometimes gets lost when switching from temporary wikitext editor to final editor.Jul 3 2018, 12:15 AM
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL