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.
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?
(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?
(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.
(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?
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".
Created attachment 247033 [details] history Note