1185420 - history.state and relative URLs are wrong when navigating back by multiple history entries from another document

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[Jim Black]

Attachment: Test case for history API bug

User Agent: Mozilla/5.0 (X11; Linux i686; rv:39.0) Gecko/20100101 Firefox/39.0 Iceweasel/39.0
Build ID: 20150703100736

Steps to reproduce:

See attached test case.  Click the three top links adds history entries via

history.pushState('state'+i, 'title'+i, '/path'+i+'/name'+i);

and then navigate to another page.  Then navigate backward by more than one entry (e.g. by right-clicking the back button and selecting the entry desired).



Actual results:

history.state and relative URLs are behaving as if I had navigated to the last state I visited before switching to another document.  In the test case:

- The popstate event is not fired.
- history.state has value "state3".
- Links pointing to relative URLs have URLs relative to "/path3/name3", the last pathname switched to before navigating away from the document.



Expected results:

- Since "pushed state3" is still there due to Firefox's fast-back feature (the document has not been torn down as in Chrome), the popstate event should be fired to indicate navigation to a previous state.
- history.state should have value "state2", "state1", or null, if I navigated back by 2, 3, or 4 entries, respectively.
- The relative links should be relative to the current URL.

Comment 1

[Jim Black]

To be clear, I've tested this in branded Firefox (Mozilla/5.0 (X11; Linux i686; rv:39.0) Gecko/20100101 Firefox/39.0) and Nightly (42.0a1 (2015-07-19)) with the same results.

Comment 2

[Jim Black]

See also the discussion at:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27188

Comment 3

[zhong.j.yu]

I'm hit by this problem too, expecting a `popstate` event that never came.

`onpageshow` is no help either because it observes an incorrect `history.state`, as Jim showed. (It does observe the correct `location.href`, in sync with the history entry, but that is not enough for state control.)

If page caching is disabled (by triggering `onunload`), the correct `history.state` will be observed in either `onpageshow` or `onload`.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Confirming. Basically, when we go back in this case we pull the page out of bfcache, but if the thing we're pulling out is not the most recent entry for the bfcached page we should in fact do some state-popping and modify the document URL accordingly, and we don't seem to be doing that.

Olli, do you know who could take a look at this?

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

It would be me or peterv.
This is about bfcache, as far as I see.