Page MenuHomePhabricator

Cursoring over an MWLinkNode takes you two characters to the right/left, not one
Closed, ResolvedPublic40 Story Points

Description

  1. Go to https://www.mediawiki.org/wiki/Project:VisualEditor_testing/MWLink and open VE.
  2. Place the cursor one character up-page of the first link ("[1]"). Press right cursor. Instead of selecting the node, you end up to the right of the node, after the space.
  3. Place the cursor one character down-page of the first link ("[1]"). Press left cursor. Instead of selecting the node, you end up to the left of the node, before the space.

Boo.

Details

Related Gerrit Patches:
mediawiki/extensions/VisualEditor : masterZero-width space to avoid empty annotation cursoring bug

Event Timeline

Jdforrester-WMF assigned this task to dchan.
Jdforrester-WMF raised the priority of this task from to High.
Jdforrester-WMF updated the task description. (Show Details)
Jdforrester-WMF added a subscriber: Jdforrester-WMF.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 16 2015, 10:12 PM
Neil_P._Quinn_WMF moved this task from To Triage to Bug Fixes on the VisualEditor board.
dchan added a comment.Apr 30 2015, 9:52 AM

Hmmm. The HTML of these links actually look like this:

...foo&nbsp;<span ce=false><a></a></span>&nbsp;bar...

i.e. the anchor tag is empty. But then the "[1]" is added as css generated content (with an ::after rule). From a browser point of view (either chromium or firefox), there is not a cursor position on each side of the <span> tag because it contains no "content".

dchan added a comment.May 2 2015, 2:24 AM

The obvious solution is to put something inside. But we have to avoid Chromium's RTL ce=false cursoring bug: https://code.google.com/p/chromium/issues/detail?id=441056

It would trigger if we put '[1]' into the actual ce=false content inside contrary-direction text, e.g.:

אַ שפּראַך
<span class="ve-ce-leafNode ve-ce-focusableNode ve-ce-mwNumberedExternalLinkNode" contenteditable="false">
<a rel="mw:ExtLink" class="external" href="http://x.com">[1]</a>
</span>
איז אַ דיאַלעקט

(Line breaks added to avoid truly dire bidi html rendering)

The effect would be that the cursor would not pass the [1]. (This is un-fixable without a bidi cursoring "oracle", because we can't tell in advance which way a leftarrow/rightarrow is supposed to move).

Change 208355 had a related patch set uploaded (by Divec):
WIP: Zero-width space to avoid empty annotation cursoring bug

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

Change 208355 merged by jenkins-bot:
Zero-width space to avoid empty annotation cursoring bug

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

Jdforrester-WMF closed this task as Resolved.Sep 22 2015, 5:24 PM
Jdforrester-WMF reopened this task as Open.
Jdforrester-WMF removed a project: Patch-For-Review.

Belay that, now it's two in both directions.

dchan added a comment.EditedSep 23 2015, 5:06 PM

Hmmm, I think I rebased too eagerly. I'm seeing mostly correct behaviour on Firefox, but much the same quirks on Chromium as before 208355.

In the long run I'd consider scrapping the display:none and generated counter, and just using real content (like the fallback content in
https://gerrit.wikimedia.org/r/#/c/207483/12/modules/ve-mw/ce/nodes/ve.ce.MWReferenceNode.js ),
together with unicode-bidi:embed to avoid crazy bidi flipping (as discussed in
https://gerrit.wikimedia.org/r/#/c/208355/6/modules/ve-mw/ce/nodes/ve.ce.MWNumberedExternalLinkNode.js ).

In the LTR case, Chromium cursors OK on constructs like this:

data:text/html,<h1 contenteditable>a <span contenteditable=false><a href='x'><span>[1]</span></a></span> sprakh</h1>

(Well it jumps too far if you shift-select, but that's not completely awful).

*However* Chromium breaks horribly in the BIDI case (and Firefox is not great either):

data:text/html;charset=utf8,<h1 contenteditable>אַ <span contenteditable=false><a href='x'><span>[1]</span></a></span> שפּראַך</h1>

DLynch added a subscriber: DLynch.Oct 22 2015, 4:52 PM

The link in step one now seems to show only a not-created page, which hurts reproduction efforts a bit.

(It also, if you try to create the page, gives a visual editor error: "Error loading data from server: ve-api: Revision IDs (doc=1537808,api=0) returned by server do not match. Would you like to retry?")

The link in step one now seems to show only a not-created page, which hurts reproduction efforts a bit.
(It also, if you try to create the page, gives a visual editor error: "Error loading data from server: ve-api: Revision IDs (doc=1537808,api=0) returned by server do not match. Would you like to retry?")

I've adjusted the link (it was database-moved), and it now is working correctly.

Are you actually still seeing this error? I tried in Chrome and Firefox, and it seems to behave correctly. i.e. the Node is selected.

Hypothesis: the fix to T114545 might have coincidentally fixed this as well.

DLynch closed this task as Resolved.Nov 13 2015, 7:23 PM
DLynch claimed this task.
DLynch added a subscriber: dchan.

I declare this fixed by incidental other changes (specifically: that other task, which stopped all non-editable node from just automatically falling back on trying to move two cursor-positions left/right after not being able to tell whether something was editable), because I can't reproduce it at all after trying in multiple browsers.