Page MenuHomePhabricator

Links to anchors within the same page trigger page previews.
Closed, ResolvedPublic3 Story Points

Description

We show page previews to the same page.

This is particularly a problem with backlinks e.g. the "^" (reference back link) in Notes section of https://en.wikipedia.org/w/index.php?title=Code_page_437 (see bug report T212419 for that particular case)

Testing

Visit https://en.wikipedia.beta.wmflabs.org/wiki/Self_link
Hover over "Section links"
Expected: No page preview
Actual: page preview to somewhere else in the page.

Acceptance criteria

  • If a link points to the same page (e.g. hash fragment or self link), it should not show a preview.
  • If a link points to another URL with a hash fragment, we show a preview for the other page.

Notes

See also: T156041

Developer notes

This might be very easy to fix just by adding another entry to the BLACKLISTED_LINKS array at the beginning of the file src/index.js.
A better, more sustainable way to fix this might be to always exclude the own page. Note this should only be done for the page popup type, not for the planned reference popup type.

Links to blacklist:

  • mw-cite-backlink a
  • href~="#"

Event Timeline

Jdlrobson created this task.Jul 2 2018, 8:45 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 2 2018, 8:45 PM
Jdlrobson updated the task description. (Show Details)Jul 2 2018, 8:46 PM
Jdlrobson added a subscriber: alexhollender.

@alexhollender I assume this is the expected behaviour, however maybe we'd want to show a special preview in this circumstance.

ovasileva triaged this task as Normal priority.Jul 3 2018, 2:08 PM
Jdlrobson raised the priority of this task from Normal to High.Dec 21 2018, 5:21 PM

Per "This issue will become more critical when the German-Community-Wishlist team starts working on adding actual reference previews (see T186129)" in T212419 bumping priority!

Jdlrobson updated the task description. (Show Details)Dec 21 2018, 5:22 PM

@Jdlrobson is there a general practice against self linking? Do you know where there is WP documentation about this? In terms of manually created self links within the article contents I wonder if this issue lies more within the editing realm?

Regarding T212419, this seems to straight-forwardly warrant a technical solution. I'd recommend removing the page preview, and potentially adding a tooltip that explains to the user what will happen if they click on the ^ (e.g. jump to use of reference).

@alexhollender links can be to different parts of the page. These are widely used across the web and in Wikipedia on large pieces of content to aid with navigation. I would recommend the solution here is to simply ignore any URI which has a hash fragment for page previews.

Jdlrobson updated the task description. (Show Details)Jan 3 2019, 8:46 PM
Jdlrobson moved this task from Incoming to Triaged but Future on the Readers-Web-Backlog board.
Jdlrobson added a project: good first bug.

In terms of manually created self links within the article contents […]

This might be a misunderstanding. Actual "self-links" in the article text are not even possible. They become bold text instead.

What's possible is to create links that point to headlines or other fragments (a.k.a. anchors) somewhere on the page, either via [[#fragment]] or [[Self link#fragment]]. The software also creates many such links, e.g. in the table of contents, as well as all the links that jump down to and up from references. All these links are technically "self-links" with a fragment attached.

I would recommend the solution here is to simply ignore any URI which has a hash fragment for page previews.

This will break page previews on links that point to an other page and have a fragment attached. These are also quite common.

I suggest to check if a link (excluding a possibly attached fragment) is identical to the current page, and not show page previews in these cases.

From an experience perspective I am fine with us not showing page previews for so called self-links. So far I cannot think of any cases where this would present an issue.

It seems that currently we are not showing a page preview when you hover over a link in the table of contents. I wonder if the way we're doing this presents a solution here? Or perhaps the implementation is too specific.

On a related note: showing some sort've preview when hovering over a link in the table of contents (not of the page, but of the respective section) seems like an interesting idea. I wonder if it was considered during the page preview design process?

On a related note: showing some sort've preview when hovering over a link in the table of contents (not of the page, but of the respective section) seems like an interesting idea. I wonder if it was considered during the page preview design process?

See T156041. The api for such a thing would be very challenging to build from a technical perspective.

ovasileva lowered the priority of this task from High to Normal.Jan 10 2019, 6:47 PM
Jdlrobson updated the task description. (Show Details)Jan 10 2019, 6:49 PM
Jdlrobson updated the task description. (Show Details)Jan 10 2019, 6:54 PM
ovasileva set the point value for this task to 3.Jan 10 2019, 6:56 PM

@alexhollender, do we really want to do this? This behavior is consistent with the way previews and URL fragments work for all other pages (T156041). Why is suppressing the preview better than showing a possibly redundant one?

If a link points to another URL with a hash fragment, we show a preview for the other page.

@thiemowmde to support this we'd need to add classes to URI's that help us distinguish between "links to other pages" and "section links"

@Niedzielski my opinion is that a page preview of the page you're currently on is more confusing than helpful. I understand from the perspective of consistency that any link should have a corresponding page preview, however given the context (you are already on the page) I think the page preview a) doesn't add value to your experience, and b) potentially confuses you (for myself at least it usually takes me a few seconds to realize that I'm looking at a preview of the page I'm currently on). I am therefore okay with breaking the pattern in this case.

I don't know the history of why we don't show page previews for TOC links, however I wonder if the decision made to suppress those could add context to this discussion?

I feel more confident suggesting that in the case of the ^ indicators in the references section page previews are distracting and should be removed, than I am in making a global suggestion against all self-links. Calling out that @Lea_WMDE has worked planned on the references section, so perhaps it's worth pausing on this until they've come up with a plan.

Heyho,

Calling out that @Lea_WMDE has worked planned on the references section, so perhaps it's worth pausing on this until they've come up with a plan.

so our work in the references section (Being able to jump back to your reading postition) is done. The work on reference previews has just started, but I don't think I see page previews in the references section in the scope of the project. But please correct me if you think otherwise :)

Change 484698 had a related patch set uploaded (by Thiemo Kreuz (WMDE); owner: Thiemo Kreuz (WMDE)):
[mediawiki/extensions/Popups@master] Also exclude the Cite extension's "Jump up" backlinks

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

Why is suppressing the preview better than showing a possibly redundant one?

This leaves me puzzled. What is the point of a popup showing the same page the user is currently reading? What new information does this reveal?

When I see a page preview popup, my expectation is that a click will "enlarge" this preview and "zoom in" on the previewed page. And indeed, this is what happens when the previewed page opens. But when the link points to the current page, there is nothing to enlarge, no new information to find, nothing new to discover. This feels like one of these infinite zooming GIFs that repeat the same information over and over again. Example: https://www.moillusions.com/infinite-zoom-coast-illusion/

to support this we'd need to add classes to URI's that help us distinguish between "links to other pages" and "section links"

It might be that I miss something. But from what I see all information is there:

  • The frontend knows which page it currently shows. The best way to get this information is, I think mw.config.get( 'wgPageName' ).
  • The Popups code knows the page titles of the page previews it is going to show.

All that needs to be done is to match these two pieces, and bail out if it's the same.

In the meantime I realized the issue with the ^ links got introduced via T206323 while the German-Community-Wishlist team worked on the Cite extension. I uploaded https://gerrit.wikimedia.org/r/484698. Note this will fix T212419, but not this ticket here.

Change 484698 merged by jenkins-bot:
[mediawiki/extensions/Popups@master] Also exclude the Cite extension's "Jump up" backlinks

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

I think the selector href~="#" is a bit too aggressive. If I link to [[Wikipedia#Community]], I would still want a preview of that page. Also, there's no way to distinguish between a link to [[Wikipedia#Community]] and [[Wikipedians]] with just a simple query selector like href~="#".

What I do think would be good to implement, as posted on https://www.mediawiki.org/wiki/Topic:V3nkf7urjggli4ut, would be either to block popups on href^="#" (because those are always links to the page you're already on), or if T156041 is implemented, as Quiddity mentions, at least restrict href="#".

Currently, this extension "conflicts" with the Kartographer extension, because it gives popups for the page you're on when you hover over the + or - zoom buttons, since those are links with a title attribute (which makes sense for what they use them for)

Jdlrobson lowered the priority of this task from Normal to Low.Wed, Jul 31, 6:53 PM

This just turned up in my inbox and I wanted to note, that the original problem described in the ticket does not exist anymore. At least I could not reproduce it. - I guess we fixed it while working on the reference previews.

Jdlrobson closed this task as Resolved.Mon, Aug 12, 6:37 PM
Jdlrobson claimed this task.

Confirmed