Page MenuHomePhabricator

VisualEditor: Link input widget should suggest section links
Open, LowPublicFeature

Description

When I edited an internal link and pasted in Work_breakdown_structure#Terminal_element as the new link target, the link editor widget thought that it was a new page, because it didn't understand that the # referenced an anchor within that page.

However, that was just a harmless warning - it did work. So I am classifying this as minor severity, because it is merely an incorrect warning message that could confuse editors.


Version: unspecified
Severity: enhancement

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:53 AM
bzimport set Reference to bz50881.
  • The link inspector needs to understand that if Foo exists, linking to Foo#Bar isn't a red link
  • Ideally the link inspector should have introspection of articles' sections so that it can suggest which headings to link to
  • This should also work for naked (local) section links - i.e., linking to just #Bar on the local page.
  • Bug 51118 has been marked as a duplicate of this bug. ***

When reporting the duplicate bug (sorry, this one didn't come up in my search) I wondered whether this was related to Bug 33094

(In reply to comment #3)

When reporting the duplicate bug (sorry, this one didn't come up in my
search)

Don't worry, it's my fault for not triaging earlier. :-)

I wondered whether this was related to Bug 33094

I don't believe so (though we should get that fixed soon too, of course).

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

Worth noting here the comments on bug 50945 about cases where display text != link text (piped links)

This isn't just a display problem, and it is NOT an enhancement - it's a real defect because editors are unlikely to take the time - as I did - to figure out how to make section links work.

Here's what happens now: The editor finds an article to link to (good UI; much better than the wikitext editor); then he/she starts typing the section link (#whatever). The link name turns red (that's the display issue), and it doesn't suggest section names (that would be a really slick enhancement; if you do this well, people are going to love you). Instead, when the editor is done typing the section information, one of four things can happen:

  • The editor presses Enter/Return (per the user guide), and the section information is REMOVED by VE. That is clearly a defect in the software.
  • The editor presses the close icon (<) (per the user guide), and the section information is REMOVED by VE. That is clearly a defect in the software.
  • The editor clicks somewhere else on the page, and the section information is REMOVED by VE. That is clearly a defect in the software.
  • The editor clicks on the area ABOVE the input box, the area containing the word "Hyperlink", and VE is happy, and saves the section information. (I'm going to add that to the user guide, but that wouldn't do nearly as much good as changing, in the software, what happens in the first three situations, above.
  • Bug 51445 has been marked as a duplicate of this bug. ***

The suggestion of the sections that can be linked are also requested at it.wp.

The VE software has changed (at least a week ago, maybe longer) for this issue. Now pressing [Return] does not remove the "#Whatever" text that the user typed, for the section link. So this bug is now primarily a display issue.

(In reply to comment #7)

This isn't just a display problem, and it is NOT an enhancement - it's a real
defect because editors are unlikely to take the time - as I did - to figure
out
how to make section links work.

Here's what happens now: The editor finds an article to link to (good UI;
much
better than the wikitext editor); then he/she starts typing the section link
(#whatever). The link name turns red (that's the display issue), and it
doesn't
suggest section names (that would be a really slick enhancement; if you do
this
well, people are going to love you). Instead, when the editor is done typing
the section information, one of four things can happen:

  • The editor presses Enter/Return (per the user guide), and the section

information is REMOVED by VE. That is clearly a defect in the software.

  • The editor presses the close icon (<) (per the user guide), and the section

information is REMOVED by VE. That is clearly a defect in the software.

  • The editor clicks somewhere else on the page, and the section information

is
REMOVED by VE. That is clearly a defect in the software.

  • The editor clicks on the area ABOVE the input box, the area containing the

word "Hyperlink", and VE is happy, and saves the section information. (I'm
going to add that to the user guide, but that wouldn't do nearly as much good
as changing, in the software, what happens in the first three situations,
above.

John reports today that "It used to be possible, in VE, to link to another section of a page (say, Bank#History). Now, when section information is added, in the Link/Hyperlink dialog box, VE just deletes it when the user presses [return] or exits (in any way) that dialog box."

(In reply to comment #11)

John reports today that "It used to be possible, in VE, to link to another
section of a page (say, Bank#History). Now, when section information is
added,
in the Link/Hyperlink dialog box, VE just deletes it when the user presses
[return] or exits (in any way) that dialog box."

Noting for posterity that that was bug 53219, which has now been fixed.

  • Bug 61428 has been marked as a duplicate of this bug. ***
Jdforrester-WMF lowered the priority of this task from High to Low.Jan 15 2015, 12:36 AM
Jdforrester-WMF set Security to None.

T112898: [Regression wmf23] On creating a wikilink/an inter-wiki link, the nice regex strips section parts of the link has been fixed but [[#section|text]] just inserted is still red (all the same, it displays correctly for links which were already present before loading VisualEditor).

When adding links to sections in the current page, the UI may be a third tab in the Link popup (after the "Search pages" and "External link" tabs) called "Section link" (or similar). In this tab, the existing section titles would be listed (possibly in a hierarchical TOC fashion) and clicking on a section would add a link to that section.

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:13 AM
Aklapper removed a subscriber: rmoen.

Change 975292 had a related patch set uploaded (by Esanders; author: Esanders):

[mediawiki/core@master] TitleWidget: Allow searching for section fragments

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

Change 975293 had a related patch set uploaded (by Esanders; author: Esanders):

[mediawiki/extensions/VisualEditor@master] Link inspector: Use searchFragments feature in TitleWidget

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

Really nice UX! 🙂
Some minor limitations I noted:

  • Added/edited headings in the current editing session are not reachable.
  • Since selecting the target page with directional keys does not fill the text input (what a browser URL bar usually does), in order to link an external section without fully typing the target page name, you have to first add a link to the page name, then edit it to add the fragment.
  • For local page section suggestions, a middle click opens the page in visual editing mode rather than reading mode like for external sections.
  • It does not recognize underscore as space equivalent; so copying the fragment from a URL looks like it is not an existing section.
  • For local sections, the resulting wikitext uselessly adds page name before fragment. (T239847)

Thanks for the feedback.
1 sounds useful and should be fixable.
I think points 2-3 can be addressed later in follow ups.
4 should be fixed, we should replace underscores when normalising.
5: if you start typing # immediately you get no page name. Removing the page name could arguably be a Parsoid job, or something we should leave in if the user types it explicitly, but we could remove it locally.

Change 976691 had a related patch set uploaded (by Sophivorus; author: Sophivorus):

[mediawiki/extensions/ParserFunctions@REL1_39] Backport fix of implicit conversion to int

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

Change 976691 had a related patch set uploaded (by Sophivorus; author: Sophivorus):

[mediawiki/extensions/ParserFunctions@REL1_39] Backport fix of implicit conversion to int

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

Tagged the wrong bug, sorry.

3 & 4 are fixed. 1 is more complicated as it requires more interaction between VE and this core component (VE needs to override the list of available sections, rather than use an API call). I think that should probably be fixed later.

Change 975292 merged by jenkins-bot:

[mediawiki/core@master] TitleWidget: Allow searching for section fragments

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

Change 975293 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Link inspector: Use searchFragments feature in TitleWidget

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

Test wiki on Patch demo by ESanders (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/dacb60851e/w/