Page MenuHomePhabricator

Incorrect cursor position in 2017 wikitext editor with syntaxhighlighting
Closed, DuplicatePublic1 Story Points

Description

I was editing a page in a narrow window. More specifically I had written the last bullet until <code> then I pasted MessageBlobStore::insertMessageBlob, then I removed the extra space and went back into the end to type </code>. When I was finished the piece of text had wrapped to the next line (as you can see from the red underlines) and cursor position was after <code>Me as seen from the screenshot below. I could continue typing and text would appear at the end as expected.

Trying to place the cursor at the end of the text is not possible. If I double-click you can see highlighting for the whole line:

To my eye this looks like the editor and the browser disagree whether there is a line break before </code>.

Event Timeline

Restricted Application added a project: VisualEditor. · View Herald TranscriptDec 1 2017, 4:21 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Deskana set the point value for this task to 1.Dec 5 2017, 7:56 PM
Deskana triaged this task as Normal priority.
Deskana moved this task from To Triage to TR1: Releases on the VisualEditor board.

Another similar issue. The blue highlight is where the middle dot really is according to the browser. There is something weird on the previous non-empty line: if I press down the cursor moves to end of the line. If I keep doing shift+right it takes 4 steps to reach the the position just before A. For some reason there seems to be empty spaces (not sure what kind of spaces) after many/all lines. Maybe copy-paste from one new wikitext editor with syntax highlighting to another one is causing some weird stuff.

Perhaps I should also mention: I had 125% in-browser zoom enabled and I have a 1.5 scaling factor enabled in KDE screen settings.

Mvolz added a subscriber: Mvolz.EditedJan 2 2018, 5:17 PM

Came here to report a similar issue :). I have a normal zoom, and I'm using Chrome on Debian.

The issue for me seems to be that the cursor has the width wrong of the characters wrong; it thinks they're much narrower than they are (as they would be with syntax highlighting off). So the further into the line I get, the more incorrect the cursor location is.

Kaartic added a subscriber: Kaartic.Jan 4 2018, 6:23 AM

I experienced the same issue some time ago and reported this with a screen cast in the Feedback board of the Visual wikitext editor but it seemed to not to have got any attention. I saw this on Firefox Nightly 59.0a1 on a Debian GNU/Linux 9 (stretch).

Perhaps I should also mention: I had 125% in-browser zoom enabled and I have a 1.5 scaling factor enabled in KDE screen settings.

I suspect zoom and scaling wouldn't play any roles in this as they should have also altered the cursor behaviour appropriately. Also, I had a normal zoom while experiencing this issue.

Elitre added a subscriber: Elitre.Jan 5 2018, 11:35 AM

How is this different from T180678?

How is this different from T180678?

T180678 seems to be exactly what I experienced (especially that recording matches well with my screencast). I'm not sure if @Nikerabbit's issue is the same too.

One more instance of misbehaviour: https://www.mediawiki.org/w/index.php?title=Topic:U45jeh8j4emlg7j5&topic_showPostId=u6huhkonhdh9yz7a#flow-post-u6huhkonhdh9yz7a

I'm an editor from China. I think that I found the same situation. But in fact, the Wikitext "editor" will misbehave when special format appear from the text( I use Chinese ), but not that easy thought about " long lines " . Because of it, I have to forget my edition in such a time... Please try to correct the mistakes in time.

The same problem is manifesting and reproducible at ml wiki too. Temporary remedy adapted is to disable both "Automatically enable all new beta features" and "New wikitext mode".
Verified the presence of problem and temporary solution in browsers {(Mozilla FF 57.0.4 (64 bit) | Chrome Version 63.0.3239.132 (Official Build) (64-bit))/ Windows 10}

Mvolz added a comment.Jan 28 2018, 7:42 PM

The same problem is manifesting and reproducible at ml wiki too. Temporary remedy adapted is to disable both "Automatically enable all new beta features" and "New wikitext mode".
Verified the presence of problem and temporary solution in browsers {(Mozilla FF 57.0.4 (64 bit) | Chrome Version 63.0.3239.132 (Official Build) (64-bit))/ Windows 10}

FYI there's a "turn off syntax highlighting" option so you don't have to turn of wikieditor entirely:

(I am no longer having this issue; not sure what changed but the font is different now.)

The same problem is manifesting and reproducible at ml wiki too. Temporary remedy adapted is to disable both "Automatically enable all new beta features" and "New wikitext mode".
Verified the presence of problem and temporary solution in browsers {(Mozilla FF 57.0.4 (64 bit) | Chrome Version 63.0.3239.132 (Official Build) (64-bit))/ Windows 10}

FYI there's a "turn off syntax highlighting" option so you don't have to turn of wikieditor entirely:

(I am no longer having this issue; not sure what changed but the font is different now.)

Oh! That seems to solve the issue for me. Let me continue to watch the effects. Thank you!

I'll repeat myself. Is this still occurring since T180678 was fixed?

I'll repeat myself. Is this still occurring since T180678 was fixed?

Assuming the fix for T180678 is in the production servers, I tested editing this page with syntax highlighting turned on and I could still observe the behaviour captured in this screencast. So, I don't think this is fixed OR more correctly I don't think T180678 is fixed OR am I misunderstanding something?

I'll repeat myself. Is this still occurring since T180678 was fixed?

Assuming the fix for T180678 is in the production servers...

No, it was in wmf/1.31.0-wmf.20, which only hit all Wikipedia's on 8 Feb. You should test again now that it has been deployed.

No, it was in wmf/1.31.0-wmf.20, which only hit all Wikipedia's on 8 Feb. You should test again now that it has been deployed.

Ok, it's Feb 17 today and I did the same test on the same page and I still see the same behaviour. IOW, I don't think it's fixed yet.

This looks like a separate issue to the font size one, which affected all pages. Filed as T187694