Last modified: 2014-10-16 11:41:48 UTC
If one is searching for a page and gets redirected and then changes to the talk page or the history page, it is not possible to navigate back in the browser history to the original redirect. Also after you went further to the history or talk page after going back the name of the redirect does not appear anymore below the article's name ("redirected from…"). I suspect that this problem occurs since the update in which it was modified that the URL shows the page to which was redirected, not the redirect page itself anymore. I consider this behaviour as wrong and also undesired (f.ex. if you need to fix the redirect after you saw the Example: In German WP [[Aeropuerto Internacional Jorge Chávez]] redirects to [[Flughafen Lima]], the redirect does not appear in the browser history. After you clicked to the talk page for instance and having clicked "back" (the left arrow in most browsers) you go back to [[Flughafen Lima]] but you cannot go back anymore to [[Aeropuerto Internacional Jorge Chávez]].
Please read: (f.ex. if you need to fix the redirect after you saw the version history or talk page)
Thanks for taking the time to report this! Providing full links here as the ones above miss a de: prefix: https://de.wikipedia.org/wiki/Aeropuerto_Internacional_Jorge_Chávez -> https://de.wikipedia.org/wiki/Flughafen_Lima Both items each do create an entry in my browser history (Firefox 32). It's correct that after clicking the talk page and going back you cannot go back one step further anymore simply because you never went to https://de.wikipedia.org/w/index.php?title=Aeropuerto_Internacional_Jorge_Ch%C3%A1vez&redirect=no before (see the redirect=no). Hence this is not a bug - it's how redirects in your browser usually work.
I think you misunderstood. I now searched and found the reason of my bug report. Implementing Gerrit change #143852 is the bug. This never should have been done. For users who work to fix redirects this new behaviour is an annoyance. Therefore reopened.
(In reply to Matthias Becker from comment #3) > Implementing Gerrit change #143852 is the bug. This never should have been > done. For users who work to fix redirects this new behaviour is an annoyance. Dealing with redirects in MediaWiki is annoying. We probably need a dedicated interface for redirects. For example, it should be possible to easily view and edit a list of incoming redirects to a page. However, I like the fact that the URL now updates for redirects and I don't imagine this feature will be reverted.
(In reply to MZMcBride from comment #4) > However, I like the fact that the URL now updates for redirects and I don't > imagine this feature will be reverted. +1 I described why the old behaviour was unfriendly from a reader's point of view in https://bugzilla.wikimedia.org/show_bug.cgi?id=48028#c0.
Why not use pushState() rather than replaceState()? IIUC, that would rewrite the url while only appending --not replacing-- the history entry, so going back to the redirect url would be possible. Or even better, we could use replaceState() to change https://de.wikipedia.org/w/index.php?title=Aeropuerto_Internacional_Jorge_Ch%C3%A1vez to https://de.wikipedia.org/w/index.php?title=Aeropuerto_Internacional_Jorge_Ch%C3%A1vez&redirect=no and then pushState() to append https://de.wikipedia.org/wiki/Flughafen_Lima to the history. So then we could "return" to the redirected page by pressing the back button, even though we were never actually there.
(In reply to Waldir from comment #6) > Why not use pushState() rather than replaceState()? IIUC, that would rewrite > the url while only appending --not replacing-- the history entry, so going > back to the redirect url would be possible. I don't think that's a good idea given how much everyone hates sites that "break the back button". Backing out of a page which happened to be a redirect shouldn't require two clicks. > Or even better, we could use replaceState() to change > https://de.wikipedia.org/w/index. > php?title=Aeropuerto_Internacional_Jorge_Ch%C3%A1vez to > https://de.wikipedia.org/w/index. > php?title=Aeropuerto_Internacional_Jorge_Ch%C3%A1vez&redirect=no and then > pushState() to append https://de.wikipedia.org/wiki/Flughafen_Lima to the > history. So then we could "return" to the redirected page by pressing the > back button, even though we were never actually there. The browser will not reload the page by itself, we'd need to reload all of the content or trigger page refresh from JS. This still breaks the back button behavior for readers who don't care what a redirect is.
(In reply to Bartosz Dziewoński from comment #7) > The browser will not reload the page by itself, we'd need to reload all of > the content or trigger page refresh from JS. This still breaks the back > button behavior for readers who don't care what a redirect is. Why would the browser have to reload the page by itself? I only proposed to have an extra entry appended to the history, that would be loaded by the normal process once the user clicks the back button. Is that not what would happen with this approach? Assuming this works as I think it does, this would indeed change the current behavior, but I wouldn't say it "breaks" it, since that is a quite common pattern on the web (when one page redirects to another, the redirect is kept in the history so one can still get back to it).
