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. :-)

matthiasbecker1967 wrote:

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.

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.

This appears to be inaccurate for users who do not have JavaScript enabled.

As such, it seems plausible that Change 143852 introduced a bug.

See T144781.

That's not true. Redirects to section always relied on JavaScript, even before this change. [Continued on T144781.]