Page MenuHomePhabricator

Shortcuts that are redirects to anchors are broken without JavaScript enabled
Closed, DuplicatePublic

Description

Per discussion here, apparently this has been an issue since October 2015, if not earlier.

First of all, let me distinguish two kinds of shortcut:

  • those intended to redirect to an article. Example: WP:N.
  • those intended to redirect to an anchor within an article, e.g. to a heading within the article. Example: WP:GNG.

The latter type of shortcut currently does not work unless the user has JavaScript enabled in their browser.

Instead of taking the user to the anchor as intended, such shortcuts simply take users without JavaScript to the top of the article that the anchor sits within. That means that instead of seeing the intended section of the article, the user instead sees the article's heading and introduction. This can potentially be very confusing for the user, if the article's introduction is of limited relevance to the circumstance that caused the user to follow the shortcut.

Such breakage is especially unhelpful in the case of Wikipedia guidelines. It is common practice for Wikipedia editors to use such shortcuts to refer to Wikipedia guidelines. This works very well if the shortcuts work, but if the shortcuts don't work, then it leaves the user confused about the editor's intended meaning, and about which aspects of the guidelines the editor was trying to draw to their attention.

I therefore feel it is important that these shortcuts should not be broken: they should work as intended, regardless of whether the user has JavaScript enabled.

To forestall any replies to the effect that all users should enable JavaScript, let me note that there are many valid reasons why users might browse without JavaScript enabled, including:

  • Performance: enabling JavaScript can slow down some computers.
  • Lack of support: some Web browsers do not support JavaScript.
  • Security: many classes of security vulnerability can be avoided by avoiding executing JavaScript in the browser.
  • Accessibility: some users find animations and other dynamic uses of JavaScript to be an accessibility impediment.

See also:

Event Timeline

Zazpot created this task.Sep 5 2016, 11:35 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 5 2016, 11:35 PM
Aklapper triaged this task as Lowest priority.Sep 6 2016, 9:51 AM

If they "are currently broken" and do not work, what does that mean? That you still end up on the correct page, just not scrolling to the correct position?
Actual results and expected results always welcome. :)

I'm afraid the problem is the redirect URL here. Wondering if this is related to https://phabricator.wikimedia.org/T37045

Setting priority to 'low' as number of non-JS clients seems to be small.

Aklapper renamed this task from Shortcuts to anchors are currently broken without JavaScript enabled to Shortcuts that are redirects to anchors are broken without JavaScript enabled.Sep 6 2016, 9:51 AM
Aklapper raised the priority of this task from Lowest to Low.

Aklapper wrote:
If they "are currently broken" and do not work, what does that mean? That you still end up on the correct page, just not scrolling to the correct position?

Correct.

I'm afraid the problem is the redirect URL here. Wondering if this is related to https://phabricator.wikimedia.org/T37045

I believe you are correct. It seems this bug was introduced with Change 143852, which is the change that was applied in order to "resolve" T37045.

That's not true. Redirects to section always relied on JavaScript, even before that change.

matmarkex wrote:
That's not true. Redirects to section always relied on JavaScript, even before that change.

[citation needed] :)

In seriousness, I have a vague memory of redirects to section having worked, without needing JavaScript, at some point in the past. Maybe I am mistaken about that, but it does seem unlikely that MediaWiki relied on JavaScript for this right from the moment that the redirect to section functionality was introduced.

It's easy enough to provide a citation even with zero knowledge of Gerrit and programming – here's an edit from 2011 that documents this behavior on the English Wikipedia: https://en.wikipedia.org/w/index.php?title=Help:Redirect&diff=prev&oldid=448019963

You could also install MediaWiki 1.23 somewhere (last version prior to the change https://gerrit.wikimedia.org/r/#/c/143852/) and see for yourself that redirects to section don't work without JavaScript.

I think we'd really like to not require JavaScript for this, but it doesn't seem possible (other than by doing T53736). I've just thought that you could use <meta http-equiv="refresh" content="0; url=#Section">, but while it seemed to work on IE and Firefox, it appears to send Chrome into an infinite redirect loop.

Zazpot added a comment.EditedSep 6 2016, 2:12 PM

here's an edit from 2011 that documents this behavior on the English Wikipedia

Thanks :) OK, so it seems this has been happening at least since 2011. Maybe for longer than that.

I think we'd really like to not require JavaScript for this,

Excellent!

but it doesn't seem possible (other than by doing T53736).

Fixing T53736 seems to me to be a legitimate course of action.

I've just thought that you could use <meta http-equiv="refresh" content="0; url=#Section">, but while it seemed to work on IE and Firefox, it appears to send Chrome into an infinite redirect loop.

Thinking aloud: if that's a legitimate Chrome bug, then hopefully the Chrome devs will accept a bug report for it and fix it, in which case the <meta http-equiv="refresh" content="0; url=#Section"> approach might be a reasonable way forward?

Either way, thanks for looking into this.

TheDJ added a subscriber: TheDJ.Sep 6 2016, 3:09 PM

I've found, that the HTTP 1.1 spec has been expanded with the ability to redirect to a fragment and that most current browsers accept this.

So that's something we might be able to add to MediaWiki. It has a few potential privacy consequences, so it would require security team to review that, caching might have to be taken into consideration etc.. but looks interesting.

Zazpot added a comment.Sep 6 2016, 4:33 PM

Related to T2218, according to 24.151.10.165.

He7d3r added a subscriber: He7d3r.Sep 7 2016, 4:35 PM
Quiddity updated the task description. (Show Details)Nov 13 2016, 10:30 PM
Tgr added a subscriber: Tgr.Nov 21 2016, 10:41 PM

I think we'd really like to not require JavaScript for this, but it doesn't seem possible (other than by doing T53736).

The fragment could be added automatically to links to redirects. It would complicate parsing though, and would only work with local wikilinks, and everyone has Javascript these days, so probably not worth it.

In the wishlist discussion it was suggested to show the section name/link in the redirection notice. That seems like a good idea.

Zazpot added a comment.EditedNov 22 2016, 2:33 AM

everyone has Javascript these days

That is false.

People surf without JavaScript for a variety of excellent reasons, including: to improve security (especially over Tor); to improve performance (especially on older hardware); or for accessibility, including via text-based browsers. The WMF should be supporting those people, even if they are a minority, because their reasons for not using JavaScript are sound.

JavaScript in web pages - especially web pages intended for a diverse global audience - should, if present, only ever be used to provide embellishments.

It should never be necessary for a user to run JavaScript in order to attain basic HTML functionality, such as having links or link fragments resolve to the correct anchors.

petr.matas added a subscriber: petr.matas.

This problem can be fixed easily. Here is a dysfunctional (as Lahwaacz pointed out below) solution based on @TheDJ's proposal: If request_URI targets a redirect to Section and request_URI does not contain any fragment part then respond with a HTTP redirect to canonical_URI#Section. Otherwise respond like MediaWiki always did.

I hope that redirecting to the same document is all right as long as at least the fragment part (#Section) is added to the original request, which did not contain any.

I have removed the subtask because this solution does not rely on it.

Examples

request_URI: https://en.wikipedia.org/wiki/WP:N
old response: 301 to https://en.wikipedia.org/wiki/Wikipedia:N
new response: 301 to https://en.wikipedia.org/wiki/Wikipedia:N

request_URI: https://en.wikipedia.org/wiki/Wikipedia:N
old response: 200 OK, contents of Wikipedia:Notability with "(Redirected from Wikipedia:N)" is sent
new response: 200 OK, contents of Wikipedia:Notability with "(Redirected from Wikipedia:N)" is sent

request_URI: https://en.wikipedia.org/wiki/WP:GNG
old response: 301 to https://en.wikipedia.org/wiki/Wikipedia:GNG
new response: 301 to https://en.wikipedia.org/wiki/Wikipedia:GNG#General_notability_guideline

request_URI: https://en.wikipedia.org/wiki/Wikipedia:GNG
old response: 200 OK, contents of Wikipedia:Notability with "(Redirected from Wikipedia:GNG)" is sent
new response: 301 to https://en.wikipedia.org/wiki/Wikipedia:GNG#General_notability_guideline

request_URI: https://en.wikipedia.org/wiki/Wikipedia:GNG#General_notability_guideline
old Response: 200 OK, contents of Wikipedia:Notability with "(Redirected from Wikipedia:GNG)" is sent
new response: 200 OK, contents of Wikipedia:Notability with "(Redirected from Wikipedia:GNG)" is sent

Result

When requesting WP:GNG, newly the following will happen:

  • one HTTP 301 redirect to a URI including a fragment part is followed,
  • contents of Wikipedia:Notability is shown,
  • notice "(Redirected from Wikipedia:GNG)" is included,
  • browser jumps to anchor General notability guideline,
  • all that without relying on JavaScript.

@petr.matas This page says right in the first sentence:

It's well known that the URL fragment (the part after the #) is not sent to the server.

So no, it is not all right to redirect to the same "document" (same URL except for the fragment), otherwise you create an infinite recursion loop.

It's well known that the URL fragment (the part after the #) is not sent to the server.

oops...

In that case we should implement wiki redirects (at least those having a fragment part, like WP:GNG does) with a proper HTTP redirect, as T53736 calls for. To be able to provide the notice "(Redirected from ...)", we can use a URL parameter, as mentioned in T20883. It will work this way:

https://en.wikipedia.org/wiki/Wikipedia:GNG will emit 302 Found and redirect to
https://en.wikipedia.org/wiki/Wikipedia:Notability?redirectedFrom=Wikipedia:GNG#General_notability_guideline. The URL parameter redirectedFrom=Wikipedia:GNG will cause insertion of the notice "(Redirected from Wikipedia:GNG)". It may also inhibit another redirection, like if redirect=no was specified.

Such URL may look ugly at first sight, but we can use JavaScript to remove the URL parameter from the address bar, if we want. Note that currently we do such displayed-URL modification as well when we change
https://en.wikipedia.org/wiki/Wikipedia:GNG (currently served with 200 OK) to
https://en.wikipedia.org/wiki/Wikipedia:Notability#General_notability_guideline.

However, keeping the parameter in the displayed URL makes sense as well:

  1. If the notice is inserted, then, strictly speaking, a slightly different document is served. Therefore its URL should be different as well.
  2. The URL with parameter explains where you are and how you got there (like breadcrumbs).
  3. After manual reload of the page (for example because some of its elements failed to load) the notice will not disappear, so it will still be possible to navigate to the redirect page.

This solution adds an extra HTTP request, but the jump to the anchor will not rely on JavaScript, so it should be faster anyway (compare opening Wikipedia:GNG and WP:Notability#General_notability_guideline) and work no matter what.

Quiddity updated the task description. (Show Details)Jun 26 2017, 9:58 PM
Quiddity added a subscriber: Quiddity.

@petr.matas I'd like to merge this task into T53736. This task seems primarily about the broken behaviour in that the section is not reached without JavaScript, which is subject of T53736.