Bug 85881 – history not correct when performing multiple operations of altering location.hash and then location.replace

• Component: History
• Status: UNCONFIRMED

[Joe Hudson]

Created attachment 140706 [details]
unit test to demonstrate issue

When performing the following steps, the history is not correctly represented

location.hash = 'start';

location.hash = 'toBeReplaced';
location.replace('...#hash1');

location.hash = 'toBeReplaced';
location.replace('...#hash2');

history.back();

In this case, I would expect, after the back execution, the hash to be 'hash1' but it ends up to be 'start';

Please see attached unit test.

[M. Dave Auayan]

This is kind of a strange bug, and I'm not sure I understand what's happening.

If you use this:

location.hash = 'start';

location.hash = 'toBeReplaced';
location.replace('...#hash1');

location.hash = 'toBeReplaced-2'; // <-- different from your unit test instructions
location.replace('...#hash2');

history.back();

... you get back to 'toBeReplaced'. 

I'm kind of expecting it to be 'toBeReplaced-2', but maybe I'm misunderstanding what the location.replace calls are doing. 

All 5 of those actions should introduce a new page in the history, no?

[Brady Eidson]

(In reply to comment #1)

> All 5 of those actions should introduce a new page in the history, no?

Why don't you run the test in the browser one step at a time and inspect the back menu after each step?

[M. Dave Auayan]

(In reply to comment #2)
> (In reply to comment #1)
> 
> > All 5 of those actions should introduce a new page in the history, no?
> 
> Why don't you run the test in the browser one step at a time and inspect the back menu after each step?

I did the first time around and replicated what Joe is reporting, and ran it again with a different fragment for the third location.hash call and ended up with Yet Another Unexpected Result, hence the confusion. As suspected, I was wrong about what location.replace is supposed to do.

[Brady Eidson]

(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > 
> > > All 5 of those actions should introduce a new page in the history, no?
> > 
> > Why don't you run the test in the browser one step at a time and inspect the back menu after each step?
> 
> I did the first time around and replicated what Joe is reporting, and ran it again with a different fragment for the third location.hash call and ended up with Yet Another Unexpected Result, hence the confusion. As suspected, I was wrong about what location.replace is supposed to do.

Interesting datum we need is before deciding this is a bug that needs code changes are:
1 - What do other browsers do?
2 - What does the spec say?

[Henri T.]

I can reproduce this bug on:
- Safari on an iPad 2 running iOS 6.1.3
- Chrome on a Galaxy Tab 2 10.1 running Android 4.1.1
- Chrome 29.0.1547.76m on windows 8 64bit
- Chrome 29.0.1547.76 on an intel mac mini running osx 10.8.4
- Safari 6.0.5 (8536.30.1) on the same osx 10.8.4 platform

I cannot reproduce this bug on:
- IE 10.0.9200.16688 on windows 8 64bit
- Firefox 24.0 on windows 8 64bit

The minimal steps to reproduce this bug are:

1. location.hash = "#a         // history.length = n
2. location.hash = "#b";       // history.length = n + 1
3. location.replace("#c");     // history.length = n + 1
4. location.hash = "#b";       // history.length = n + 1 (!)
5. history.back();
// expected behavior: hash == "#c". problem behavior: hash == "#a"

In practical terms, open a web console on any web page, and paste and run this line:

location.hash="#a"; location.hash="#b"; location.replace("#c"); location.hash="#b"; history.back()

If you end up with #a in your browser location bar, you have reproduced the problem.

Notes:
- history.length does not change when step 4. runs. 
- if step 4 is instead location.hash = "#d";, the bug does not appear.
- Effectively, webkit partially behaves as if the current history entry was still "#b" when it is in fact "#c".

[Dawn Brice]

Created attachment 247033 [details]
history

Note