1535705 - Website performs redirect and then I can't recover the URL I was trying to go to

Status: NEW

(Firefox :: General, enhancement, P5)

Description

[Dori]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

I've noticed this behavior in WaPo sites which require subscription after a period of time. I'll follow a direct link to an article, the website will perform some checking, realize that I've exceeded my limit, and then redirect to the main page.

The browser only displays the main website and I've lost the original URL that I followed. The Back button is greyed out. Firefox shouldn't allow a website to dictate whether I can go back or not.
Steps:

1. View enough articles at https://www.washingtonpost.com/ to exceed the limit.
2. Open a new window (don't delete any cookies, not a private window).
3. Follow a specific article to WaPo, e.g.
   https://www.washingtonpost.com/world/national-security/a-shadowy-group-trying-to-overthrow-kim-jong-un-raided-a-north-korean-embassy-in-broad-daylight/2019/03/15/ae4208a4-c451-4886-b608-f5ac1f182d3d_story.html
4. You get redirected to https://www.washingtonpost.com

Actual results:

I'm unable to go back to specific article URL that I followed.

Expected results:

This doesn't mean that Firefox should be able to let you circumvent whatever logic WaPo has put in, but you should be able to hit back and go to that original URL, and then redirected again to https://www.washingtonpost.com. As it is the back button is blank even though the displayed URL has changed.

Comment 1

[Gingerbread Man]

Probably a duplicate of bug 639952.

Comment 2

[Neha Kochar [:neha]]

Attachment: back button available showing history

Comment 3

[Neha Kochar [:neha]]

I tried this and the back button is not greyed out, it is available but clicking on it keeps me on the same page anyway and that is expected I believe because the website is asking to sign up for subscription.
I'll attach a snapshot of the history being available (although in dup which is a different bug).
Also, ni'ing Boris to confirm that this is expected correct behavior.

Comment 4

[Boris Zbarsky [:bzbarsky]]

So just to make sure I understand the steps to reproduce:

1. We are starting with a brand-new tab in which nothing has been loaded before.
2. We are doing a pageload of url A.
3. That pageload performs a navigation to url B.
4. Url A is no longer present in session history. Since nothing was present there before, there is nothing to go back to.

Is that right? This could happen in several different ways. The page could be doing an HTTP redirect from A to B, so that A is never even loaded. It could be doing location.replace(B) in script on A, which is defined by web standards to replace A with B in the session history. It could be just doing location.href = B during pageload, which is likewise defined by web standards to replace A with B in the session history.

I agree that it would be useful to have a UI feature for "the URL I was trying to load before redirects happened", but that would be a pure UI feature, not something on the document navigation level.