Page MenuHomePhabricator

VisualEditor: Link inspector should make it easier to change the label
Closed, DuplicatePublic


There's a few problems, if we end up solving them in different ways we should create separate bugs for one or more of them.

  1. Changing the label of an internal link

Given a simple link like [[example]] or [[Example]] (e.g. no custom label), when changing the link target, it seems to the user that the link has not updated since the label (which is all we see in the editor, hovering the link does nothing since it isn't a clickable link in edit mode).. since the label has not changed.

Now one could argue the label shouldn't update at this point so that the sentence still reads the same (e.g. when changing intending to change the link from "He was [[foolian]]." to "He was [[Foo|foonier]].") and to be consistent for cases where the link does have a custom label (in which case it is more likely the label should stay the same?).

However given the following two cases:

  • "... is an [[United States|American]] thing ..." -> " is a [[Germany|German]] thing ..."
  • "... according to [[David Tennant]] ..." -> " according to [[Russell T Davies]] ..."

It is very common that the label should change to the target automatically (the second case) or at least be easy to change right after (first case). Ideally for the first case above it would automatically change to Germany and then the user can correct it to German.

  1. Change the label of any link

Whether internal or external, it seems quite difficult to change the label of a link. When selecting the entire link text and typing over it, it currently behaves as follows:

> Some <a>link</a>
Select link (has to be done manually (tedious and error prone)
> Some [selection]<a>link</a>[/selection]"
Type "hello".
> Some <a>h</a>ello.


Though I'm open to other ideas, I'd recommend we start by putting an input field in the link inspector for the label so that they can be changed together. Though even without that, one should be able to replace the label without opening the inspector or running into the weird "<a>first char</a>other chars" case.

Version: unspecified
Severity: normal
See Also:



Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 2:02 AM
bzimport set Reference to bz51438.

We shouldn't put a label input in the link inspector because:

  1. It doesn't support rich text
  2. We cannot and should not put a subsurface in an inspector
  3. Links should remain a lightweight task, and dialogs are not lightweight
  4. This doesn't elegantly solve the problem anyway

Some steps towards a better approach:

  1. We could decorate the "linked" portion of a link differently than the link trail portion - at lease during certain interactions.
  2. We could add extra cursor positions on each side of a link to indicate being next to or inside the link tag, decorate the link when you are inside those boundaries.

I think this duplicates Bug 50945

I'd rather have a label input (or at least a label display) in the link inspector, but some method of indicating that the link is piped or has separate trailing text is important.

If you see a redlink like "Alice Expert", you can't tell from looking at the link in VisualEditor that it's actually piped: [[Alice D Expert|Alice Expert]]. Fixing the label to match the actual article title name ("Alice D. Expert") does not fix the broken link.

There's no way to see that the redlink didn't get fixed when you changed the label to "Alice D. Expert" (because VisualEditor's "red" links are blue).

There is also no reason for you to suspect that the problem is due to a hidden piped link, because there is no visual cue that you need to go into the link inspector to address the hidden/piped link.

Here's a link that shows one of the main problems with the current approach:

The editor almost certainly did not intend to end up with [[15 October|14 October]], and the editor almost certainly does not know that his effort to change the link failed.

  • This bug has been marked as a duplicate of bug 53973 ***