Last modified: 2014-09-21 00:25:32 UTC
Modern browsers include a history api including pushState/popState/replaceState support. Using these apis one can dynamically alter the path portion of the address in the address bar without leaving the page. Additionally if you use replaceState you don't create side effects in forward/back history. Using this api it's possible to make [[Wikipedia:Redirection]]'s /wiki/Redirection dynamically change to /wiki/Redirect in the user's browser. I've been experimenting with a script to do that: https://en.wikipedia.org/wiki/User:Dantman/vector.js We should consider fine tuning code to do this and including it in core. From the user perspective this would have a similar effect to using 301s. It would make end users end up copying the canonical url instead of the redirect's url.
Well, it's about time we did this already.
Change 143852 had a related patch set uploaded by Bartosz Dziewoński: On redirect, actually rewrite page URL to the target one with JavaScript https://gerrit.wikimedia.org/r/143852
*** Bug 48028 has been marked as a duplicate of this bug. ***
Change 143852 merged by jenkins-bot: On redirects update the URL to that of the target page with JavaScript https://gerrit.wikimedia.org/r/143852
Yay!
Seems that replaceState on IE10 is not scrolling to the anchor position.
Filed as bug 70176, I'll look into it.
This is awesome. Thank you, Bartosz!
Just wondering, why not to use a server-side redirect?
That's been discussed on bug 18883: we wouldn't be able to display the "Redirected from" message. We also probably wouldn't be able to support redirects to sections if we did that (but I don't think anybody has done cross-browser testing) and it would probably require additional work on the ops side of things (but I don't think anybody has looked into this either). The "Redirected from" is the primary reason.
Now MediaWiki behaves very differently with JavaScript disabled. Why wouldn't the "Redirected from" message work with a server-side solution?
To be clear, I don't oppose the change per se, in fact I even wrote a JS hack for it: [[m:User:Ricordisamoa/SkipRedirect.js]]
(In reply to Ricordisamoa from comment #11) > Now MediaWiki behaves very differently with JavaScript disabled. Yes > Why wouldn't the "Redirected from" message work with a server-side solution? So, if you did it server-side, where would you redirect to? Not just the canonical path because then how does the server detect that the followup needs to show the redirected from msg? and if you create a new style of URL (e.g. ${canonical}?rdfrom=origtitle) to redirect to then we have extra complexity and it's still not landing at the canonical URL. unless we did both ?rdfrom and also pushstate to remove the rdfrom param. but that's no better than what's deployed now.
(In reply to jeremyb from comment #13) > how does the server detect that the followup needs to show the redirected from msg? Would it be possible to pass a 'rdfrom' POST parameter to the target page?
(In reply to Ricordisamoa from comment #14) > (In reply to jeremyb from comment #13) > > how does the server detect that the followup needs to show the redirected from msg? > > Would it be possible to pass a 'rdfrom' POST parameter to the target page? No. And even if possible client side (which it's not) we wouldn't anyway because of implications for varnish.
I've a researcher who has studied redirects in Wikipedia. I'm also active from time to time on https://en.wikipedia.org/wiki/Wikipedia:Redirects_for_discussion where we very frequently use viewership statistics to make decisions on which redirects to keep. I wanted to confirm that I understand the effect of this patch on that data that Wikimedia publishes. Here's my understanding: To date, views to redirects count as a views to the redirect page from the perspective of our view-tracking software (e.g., on http://stats.grok.se/). This patch will make it appear, from the browser's URL bar and browser history, that the user is visiting the target page. This patch will not change the way that views are recorded in our view log tables. Things will continue to be recorded in the view logs published by WMF just as they have before. If, however, we were to use any data stored by a users personal history file stored in their browser, the fact that users visited a redirect (and not the target page directly) would disappear. Is that all correct?
(In reply to jeremyb from comment #13) > (In reply to Ricordisamoa from comment #11) >> Now MediaWiki behaves very differently with JavaScript disabled. > > Yes Can someone please elaborate on the "very different" behavior here? Specifics would help. (In reply to Benjamin Mako Hill from comment #16) I believe your understanding is correct, yes. P.S. Hi! Nice to see you active here. :-)
I consider resolving this bug IS a bug. For people who work with redirects, as for example fixing them, moving pages and so on, after looking into another page like the version history or the talk page you can't go back by hitting the left arrow in your browser that is pretty annoying, especially i you forgot to note the name of the redirect you came through – you simply have no possibility to find again the redirect easily, if so. Also, if I understand comment # 16 correctly it became impossible to distinguish how many users came through which redirect and therefore the possibility is lost to determine which redirects are useful and which are not or if the construct of a disambiguation page should be modified or not. This should be reverted to the former behaviour.
(In reply to Matthias Becker from comment #18) > I consider resolving this bug IS a bug. For people who work with redirects, > as for example fixing them, moving pages and so on, after looking into > another page like the version history or the talk page you can't go back by > hitting the left arrow in your browser that is pretty annoying, especially i > you forgot to note the name of the redirect you came through – you simply > have no possibility to find again the redirect easily, if so. When you land on a redirect the "Redirected from" is still there. And (at least as far as testing in Firefox goes) when I land on a redirect, go to history, then press back the page I go back to still has the "Redirected from" line there. The UI/workflow for people working with redirects is still there. > Also, if I understand comment # 16 correctly it became impossible to > distinguish how many users came through which redirect and therefore the > possibility is lost to determine which redirects are useful and which are > not or if the construct of a disambiguation page should be modified or not. No, the address bar change is done by JS after load. The HTTP request for redirect pages is still the same URL and logs can still distinguish when a user lands on the canonical page or the redirect.
