Boo.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Zero-width space to avoid empty annotation cursoring bug | mediawiki/extensions/VisualEditor | master | +13 -1 |
Hmmm. The HTML of these links actually look like this:
...foo <span ce=false><a></a></span> 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".
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
Change 208355 merged by jenkins-bot:
Zero-width space to avoid empty annotation cursoring bug
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>
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?")
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.
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.