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

Assigned To

None

Authored By

	Nikerabbit
	Dec 1 2017, 4:21 PM

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>.

Related Objects

Mentioned In: T198015: Syntax highlighting in wikitext editor interacts badly with the responsive design mode of Firefox
Mentioned Here: T187694: Incorrect cursor position on pages with wrapped tabs (2017WTE + SyntaxHighlighting)
T180678: Text and selection are shifted

Event Timeline

Nikerabbit created this task.Dec 1 2017, 4:21 PM

Restricted Application added a project: VisualEditor. · View Herald TranscriptDec 1 2017, 4:21 PM

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

The page in question: https://www.mediawiki.org/wiki/User:Nikerabbit/Monthly_report/2017-09

• Deskana triaged this task as Medium priority.Dec 5 2017, 7:56 PM

• Deskana set the point value for this task to 1.

• 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.

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.

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).

In T181816#3867683, @Nikerabbit wrote:

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 subscribed.Jan 5 2018, 11:35 AM

How is this different from T180678?

In T181816#3877828, @Elitre wrote:

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.

Viswaprabha subscribed.Jan 28 2018, 7:22 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}

In T181816#3926809, @Viswaprabha wrote:

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:

Screenshot from 2018-01-28 19-39-02.png (474×561 px, 27 KB)

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

In T181816#3926813, @Mvolz wrote:

In T181816#3926809, @Viswaprabha wrote:

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?

In T181816#3940817, @Elitre wrote:

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?

In T181816#3942938, @Kaartic wrote:

In T181816#3940817, @Elitre wrote:

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.

Esanders closed this task as a duplicate of T180678: Text and selection are shifted.Feb 12 2018, 8:16 PM

In T181816#3965062, @Esanders wrote:

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

Kaartic mentioned this in T198015: Syntax highlighting in wikitext editor interacts badly with the responsive design mode of Firefox.Jun 23 2018, 3:38 PM

	F12851829: Screenshot from 2018-01-28 19-39-02.png
	Jan 28 2018, 7:42 PM

	F12208801: image.png
	Jan 2 2018, 4:38 PM

Incorrect cursor position in 2017 wikitext editor with syntaxhighlightingClosed, DuplicatePublic1 Estimated Story PointsActions

Description

Related Objects

Event Timeline

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