redirectToFragment script (redirects to section headers) behaving unreliably
Closed, ResolvedPublic

Description

Due to T107399 it seems that the reliability our mediawiki.action.view.redirect.js has gone down considerably. Sometimes it works sometimes it doesn't.

Multiple people on WP:VP/T have reported problems with this.
https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Shortcuts
(also here)

TheDJ created this task.Aug 27 2015, 9:09 AM
TheDJ added a project: JavaScript.
TheDJ added a subscriber: TheDJ.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 27 2015, 9:09 AM
NQ added a subscriber: NQ.Aug 27 2015, 10:45 AM

Where can that "redirectToFragment script" be found?

TheDJ added a comment.Aug 27 2015, 3:44 PM

resources / src / mediawiki.action / mediawiki.action.view.redirect.js

This has been reported in the 64-bit Chrome version 45.0.2454.46 as well as in Microsoft Edge version 20.10240.16384.0. The behavior appears to be new (during the last week).

In Chrome, this link works: https://fr.wikipedia.org/wiki/Special:Préférences#mw-prefsection-betafeatures

In Safari (several versions/couple of years) that link does not work; you end up on the main page of Special:Preferences rather than on the Beta Features page.

Whatamidoing-WMF set Security to None.

This has been reported in the 64-bit Chrome version 45.0.2454.46 as well as in Microsoft Edge version 20.10240.16384.0. The behavior appears to be new (during the last week).

In Chrome, this link works: https://fr.wikipedia.org/wiki/Special:Préférences#mw-prefsection-betafeatures

In Safari (several versions/couple of years) that link does not work; you end up on the main page of Special:Preferences rather than on the Beta Features page.

Special:Preferences has it own script to select a tab from the anchor -> mediawiki.special.preferences.js
You should create an own task for that

redirectToFragment script is for redirects like https://en.wikipedia.org/w/index.php?title=Wikipedia:NOPIPE&redirect=no which contains an anchor part and that you will redirect when going to the redirect - https://en.wikipedia.org/wiki/WP:NOPIPE

matmarex triaged this task as "High" priority.Aug 27 2015, 9:10 PM
matmarex added subscribers: Krinkle, ori.
matmarex added a subscriber: matmarex.

As far as I know, browsers respect changing the URL "fragment identifier" (the part after '#') by scrolling to the element in two cases:

  1. if it happens after the element is already rendered (the scroll is immediate)
  2. or if it happens before anything has rendered (in which case the scroll happens after the element appears).

If we fire off our script asynchronously, we risk changing the URL while the page is being rendered, which has no effect in the common browsers. (Firefox is likely also affected, but we have a workaround for some old bug it had where the second case did not work at all, and so we always do the first case too, on document ready.)

We need to either switch to using the first case (jumping to the second only after everything is loaded), which will fire later than it did before it broke and thus is likely to be somewhat annoying for users; or make the script run synchronously in the head again, which might require too much hackery. We might be able to put a simplified version of it (without any browser-specific code, it becomes just a few lines) into OutputPage::getInlineHeadScripts(), perhaps?

He7d3r edited the task description. (Show Details)Aug 27 2015, 9:12 PM
TheDJ added a comment.Sep 14 2015, 1:57 PM

For Safari, this Safari issue, that is also plaguing angular, might be relevant: https://openradar.appspot.com/22186109

matmarex changed the title from "redirectToFragment script behaving unreliably" to "redirectToFragment script (redirects to section headers) behaving unreliably".
matmarex added subscribers: Schnark, Keegan.

I am pretty sure this is a regression from Performance team's work on ResourceLoader, as explained in the previous comment.

ori moved this task from Inbox to Backlog on the Performance-Team board.Nov 2 2015, 7:40 PM
ori added a subscriber: dr0ptp4kt.Nov 2 2015, 8:18 PM

I am pretty sure this is a regression from Performance team's work on ResourceLoader, as explained in the previous comment.

There were a number of covert defects that the ResourceLoader changes exposed but did not introduce, like T115692. mediawiki.action.view.redirect.js needs to not depend on synchronous loading behavior. I think this is properly within the purview of Reading-Web-Backlog. @dr0ptp4kt, ping.

5 people managing 15+ extensions. This one isn't showing up on our dashboard. Is there a project we can own to track these kind of bugs e.g. mediawiki-interface so it appears on;
https://phabricator.wikimedia.org/dashboard/view/125/

I'll take a pass through the other high bugs and work out if they are really high so we can give this more attention.
Arrgh.

Now tracked on https://phabricator.wikimedia.org/dashboard/manage/125/ no need for reading web tag, it's on our radar.

TheDJ added a comment.Nov 12 2015, 8:51 AM

Came up again on VP/T. BTW, there is a related ticket T67468 about the workings of FF + redirectToFragment, that might be of interest.

jhobs claimed this task.Dec 7 2015, 5:51 PM
jhobs reassigned this task from jhobs to Jdlrobson.Dec 14 2015, 10:35 PM

Change 259190 had a related patch set uploaded (by Jdlrobson):
Explicitly scroll to element in hash

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

Change 259190 merged by jenkins-bot:
mediawiki.action.view.redirect: Explicitly scroll to element in hash

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

Jdlrobson closed this task as "Resolved".Dec 18 2015, 12:48 AM