Page MenuHomePhabricator

Parsoid: Linking on a part of a word triggers linktrail
Closed, ResolvedPublic1 Estimated Story Points


I want to get:

I want two <a href="/wiki/apple">apple</a>s.

so I input "I want to apples." then add link to "apple" on "apple". It then generates wikitext "I want two [[apple|apple]]s." which is rendered as:

I want two <a href="/wiki/apple">apples</a>.

Version: unspecified
Severity: normal
See Also:



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:59 PM
bzimport set Reference to bz33091.

How is this a Visual Editor bug?

If you type [[apple]]s in a normal wiki page the linktrail will make the s part of the link.

The expected wikitext would be [[apple]]<nowiki />s (or something that has the same effect). Alternatively, the VisualEditor should correctly display the entire word as a link when a user tries to link part of a word, as the HTML resulting from such wikitext would ordinarily produce. The bug is the inconsistency between the display and the wikitext.

Confirmed that this is still the behaviour in current version of VE.

Expected behaviour? Certainly, shouldn't created [[A|A]]pple - at best, [[A]]<nowiki></nowiki>pple, if we want to suport this.

Mass-moving items into VisualEditor product

Mass-move out of "General" to "Data Model".

Problem is that Parsoid is wrong converting:

<a foo>foo</a>bar

... into:


... rather than


which though ugly is the correct wikitext for this.

Except that only takes strict conversion into account, not the whole picture.

We don't use [[foo]]<nowiki/>bar in articles. While it should be possible to do. It should not be something that WYSIWYG users should inadvertently do by accident.

This should probably be handled with two changes:

  • For strict conversion <a>foo</a>bar should be converted properly to [[foo]]<nowiki/>bar
  • The UI of the visual editor should have a change to the user's interaction with link creation to make it harder to accidentally create things like <a>foo</a>bar.

I'm not quite sure what the ui change should be. Perhaps something like making it so that when you try to create a link the selection might be altered to cover the full word. Something that would require the user to force the editor to use the selection that would create a <nowiki/> instead of just accepting it as-is.

Whatever the case, we do not want the user who partially selects a run of text and turns it into a link to inadvertently create a <nowiki/> when they likely intended to make a link of the whole thing.

Agree that we might want to consider adjusting the UI to hinting on this - have added as a see-also.

(In reply to comment #8)

Agree that we might want to consider adjusting the UI to hinting on this - have
added as a see-also.

see also self?

Mass-moving bugs into the new 'Parsoid' product.

Works in tests, but does not yet work correctly in the VE. Needs further investigation.

Patch that fixes escaping with latest JSDOM submitted in

  • Bug 44779 has been marked as a duplicate of this bug. ***

Not actually fixed:

$ echo '<a href="Bar" rel="mw:WikiLink">Bar</a>Baz' | node js/tests/parse.js --html2wt

$ echo 'Foo<a href="Bar" rel="mw:WikiLink">Bar</a>Baz' | node js/tests/parse.js --html2wt

(against current master)

  • Bug 41160 has been marked as a duplicate of this bug. ***

Related URL: (Gerrit Change I627dd609d4eb00080c61628306ad8c3aea7a9077)

The above commit has been merged.

Verified in production - highlighting a portion of apples and applying a link - seamlessly creates:
I want two [[apple]]<nowiki/>s