If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Pushstate and redirects break user history

NEW
Unassigned

Status

()

Core
Document Navigation
5 years ago
2 years ago

People

(Reporter: thepope+mozilla, Unassigned, NeedInfo)

Tracking

Trunk
Other
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (iPad; CPU OS 6_1_2 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10B146 Safari/8536.25

Steps to reproduce:

Open page (www.example.org)
Pushstate to history with a URL that has a 301/302 redirect (www.example.org/test)
Navigate away (www.example.org/foo)
Browser Back
Browser Back

So www.example.org/test is a 301 redirect to another page on the same domain.


Actual results:

Ended in a redirect loop in history so user cannot get back to the first page (www.example.org). Pushstate creates the history item for the page /test but going back triggers the redirect and then going back again triggers the redirect again etc.


Expected results:

The redirect should be detected and removed from history. This works in both WebKit and IE10.
(Reporter)

Updated

5 years ago
Version: 21 Branch → 19 Branch
Perhaps bug 873864 is related to this?
Can someone please confirm this bug?

/be
Needs an actual testcase.  www.example.org does not work, since it does a cross-domain redirect so you can't pushstate usefully as in the steps to comment 0.
Flags: needinfo?(thepope+mozilla)

Comment 4

3 years ago
I can't reproduce on current nightly on OS X with the following steps:
1) Run `python -m SimpleHTTPServer`
2) Open http://localhost:8000/
3) Open the Web Console and run:
history.pushState({}, "", "?will_be_redirected");
history.pushState({}, "", "foo");
4) Go back using the toolbar button
5) Go back using the toolbar button

On step 4 I get back to the http://localhost:8000/?will_be_redirected URL, which does not redirect, so going back again works just fine.

If I load the http://localhost:8000/?will_be_redirected URL from the location bar, it 301 redirects to http://localhost:8000/?will_be_redirected/, so this seems to match the requirements outlined in comment 0.

I'm resolving this, but please reopen with more specific steps to reproduce!
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 5

2 years ago
Hi
Status: RESOLVED → UNCONFIRMED
Flags: needinfo?(thepope+mozilla)
Resolution: WORKSFORME → ---
Version: 19 Branch → 38 Branch
(Reporter)

Comment 6

2 years ago
Created attachment 8611253 [details]
Testcase node http server for pushstate redirect problems
(Reporter)

Comment 7

2 years ago
Hi,

Sorry to reopen this but still having issues with this. I have attached a testcase which is small node http server to reproduce the problem. The error is slightly different now with the later FF versions, in that I dont get a redirect loop, I instead get a situation where the redirect is not respected.

If you run the example using node, the expected result is that browsing back after the last pageload should render "Redirected resource" but instead it renders the page where the pushState was added. For comparison Chrome does produce the expected behaviour.

Updated

2 years ago
Component: Untriaged → Document Navigation
Product: Firefox → Core
Since your testcase is not self-executable in the browser, please provide detailed instructions on how to get it working (assume the person testing does not have any dependencies set up). Thank you.
Flags: needinfo?(thepope+mozilla)
(Reporter)

Comment 9

2 years ago
Sorry, this wasn't possible to reproduce in the browser alone so the testcase is a http server using nodes standard libs. 

To reproduce:

* Run the server using `node testcase.js`
* open http://localhost:8000
* Click start (goes to http://localhost:8000/test)
* In console enter `history.pushState({}, null, '/redirect');`
* Click the "here" link, or goto http://localhost:8000/pageload
* Navigate back using browser back button

Expected result:

On navigating back I expect the page to render "Redirected resource"

Actual result:

I get the content of the `http://localhost:8000/test` page rather than the redirected page, so the browser is ignoring the redirect and just rendering the page the pushstate happened on again.

Navigation I get:

http://localhost:8000/pageload
http://localhost:8000/redirect
http://localhost:8000/test

But I am expecting:

http://localhost:8000/pageload
http://localhost:8000/redirected
http://localhost:8000/test
Flags: needinfo?(thepope+mozilla)
Thanks, I can reproduce this in the latest Nightly but not in Chrome 43. Interestingly if I close and restore the tab after pressing the back button I get the Redirected page.
Status: UNCONFIRMED → NEW
Ever confirmed: true
As near as I can tell this has always been the behaviour in Firefox; not to say this isn't a bug, just that I don't think it's a regression.
Version: 38 Branch → Trunk

Comment 12

2 years ago
I believe I have been experiencing a version of this bug, but in my case, the Firebug add-on was the culprit. I used Firebug 2.0.9.1 and Firefox 38.0.1 on OSX 10.10.3.

1. Open a new tab. Press F12 to engage the Firebug console.
2. Navigate to any website. For simplicity choose one without a redirect,  e.g. http://perl.com
3. Navigate to a site on my intranet http://example.com/abc which sends a HTTP 302 redirect to example.com/?abc=1

 example.com/abc and example.com/?abc=1 produce the same content, which includes this code:
     if (location.href=='http://example.com/?abc=1') {
        history.replaceState({},'','http://example.com/abc');
     }
So at this point the address bar changes as expected to http://example.com/abc
If I right click on the back button, the history shows two entries:  perl.com and example.com
5. I press the back button, and I get perl.com as expected.
6. I press the forward button, I get example.com/?abc=1 which relabels as expected.
However, the history now contains two entries, both of which are example.com. The back button now has no effect because I seem to be already at the beginning of the history.

If you repeat the experiment with Firebug disabled (or restart Firefox and never open a Firebug console) then you get a different result: both perl.com and example.com remain in the history and you can go back and forth with the back and forward buttons with no strange effects.

Comment 13

2 years ago
I have documented my experiences (in Comment 12 above) in a new issue ticket in the Firebug bug database here: https://code.google.com/p/fbug/issues/detail?id=7805
(Reporter)

Comment 14

2 years ago
In my tests I used a fresh install of FF with no add-ons, so I dont think this is related to Firebug.
Olli, do you have time to look at this?
Flags: needinfo?(bugs)
Flags: needinfo?(bugs)
Realistically probably not real soon at least.
Flags: needinfo?(bugs)
You need to log in before you can comment on or make changes to this bug.