matthiasbecker1967 wrote:

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.

matthiasbecker1967 wrote:

I think you misunderstood. I now searched and found the reason of my bug report.

Implementing gerrit 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.

zeratul976 wrote:

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