Last modified: 2013-06-27 22:41:30 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T51985, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 49985 - VisualEditor: Adjacent link annotations (one of which is from Parsoid, one from VisualEditor) should conjoin
VisualEditor: Adjacent link annotations (one of which is from Parsoid, one fr...
Status: RESOLVED FIXED
Product: VisualEditor
Classification: Unclassified
Editing Tools (Other open bugs)
unspecified
All All
: Highest normal
: VE-deploy-2013-07-04
Assigned To: Ed Sanders
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-21 22:55 UTC by Ryan Kaldari
Modified: 2013-06-27 22:41 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Ryan Kaldari 2013-06-21 22:55:14 UTC
Steps to reproduce:
1. Insert the cursor immediately after the first letter of a link
2. Hit delete/backspace
3. Type a new character
4. The new character isn't part of the link, so select the entire word and click the link button
5. Re-enter the link article
6. Save your changes

Expected result:
If you started with "[[Porcupine]]", you should end up with "[[porcupine]]".

Actual result:
If you started with "[[Porcupine]]", you end up with "[[porcupine|p]][[Porcupine|orcupine]]".

This is just a common use case demonstrating a more general bug. Namely, if you create a new link that subsumes an existing link, the existing link is preserved within the new link instead of being replaced.
Comment 1 James Forrester 2013-06-21 22:56:55 UTC
Ed, is this due to the DM stuff around adjacent annotations?
Comment 2 Ed Sanders 2013-06-23 10:07:54 UTC
Similar but different. This case should definitely be fixed in VE, not Parsoid.
Comment 3 Roan Kattouw 2013-06-24 01:10:43 UTC
There are two issues here.

First off, we should change getComparableObject() for MWInternalLinkAnnotation to normalize the title and possibly tweak other things to the point where links to the same title are comparable, even if they have different capitalizations or space-vs-underscore variants of that title. That will be both more semantically correct and serve as a workaround for this bug.

Secondly, because we want to stop merging comparable but different annotations in the converter, we need Parsoid to correctly process at least things like <a href="Porcupine">p</a><a href="Porcupine">orcupine</a> (adjacent <a>s with the same href) and possibly <a href="porcupine">p</a><a href="Porcupine">orcupine</a> as well (adjacent <a>s with different hrefs that normalize to the same title).
Comment 4 Gerrit Notification Bot 2013-06-26 13:59:05 UTC
Related URL: https://gerrit.wikimedia.org/r/70633 (Gerrit Change I5fb5bfc69c344ca4ce4803d7b6116074648a8d7e)
Comment 5 Gerrit Notification Bot 2013-06-27 17:30:02 UTC
Change 70633 merged by jenkins-bot:
Fix comparison of MW internal links

https://gerrit.wikimedia.org/r/70633
Comment 6 James Forrester 2013-06-27 17:45:14 UTC
(In reply to comment #5)
> Change 70633 merged by jenkins-bot:
> Fix comparison of MW internal links
> 
> https://gerrit.wikimedia.org/r/70633

And with that change, this bug is fixed; closing. It will be deployed this afternoon.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links