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)
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| mediawiki.action.view.redirect: Explicitly scroll to element in hash | mediawiki/core | master | +9 -6 |
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
As far as I know, browsers respect changing the URL "fragment identifier" (the part after '#') by scrolling to the element in two cases:
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?
For Safari, this Safari issue, that is also plaguing angular, might be relevant: https://openradar.appspot.com/22186109
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 Web-Team-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.
Came up again on VP/T. BTW, there is a related ticket T67468 about the workings of FF + redirectToFragment, that might be of interest.
Change 259190 had a related patch set uploaded (by Jdlrobson):
Explicitly scroll to element in hash
Change 259190 merged by jenkins-bot:
mediawiki.action.view.redirect: Explicitly scroll to element in hash