85881 2012-05-08 06:46:50 -0700 history not correct when performing multiple operations of altering location.hash and then location.replace 2021-03-31 09:05:27 -0700 1 1 1 Unclassified WebKit History 528+ (Nightly build) Mac (Intel) OS X 10.7 UNCONFIRMED P2 Normal --- 0 joehud webkit-unassigned abarth beidson eric fishd henrit japhet jjjaquanrice kpdecker m ryan oldest_to_newest 618470 0 140706 joehud 2012-05-08 06:46:50 -0700 Created attachment 140706 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. 849351 1 m 2013-03-06 15:12:14 -0800 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? 849404 2 beidson 2013-03-06 16:05:22 -0800 (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? 850396 3 m 2013-03-07 12:57:31 -0800 (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. 850400 4 beidson 2013-03-07 12:59:15 -0800 (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? 936018 5 henrit 2013-10-03 16:07:49 -0700 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". 1070931 6 247033 dawnelle.m.brice 2015-02-20 18:49:52 -0800 Created attachment 247033 history Note 140706 2012-05-08 06:46:50 -0700 2012-05-08 06:46:50 -0700 unit test to demonstrate issue test.html text/html 2266 joehud PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiIgCiAgICAgICAgICAgICAgICAgICAgImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xv b3NlLmR0ZCI+CjxodG1sPgo8aGVhZD4KICA8c2NyaXB0IHNyYz0iaHR0cDovL2NvZGUuanF1ZXJ5 LmNvbS9qcXVlcnktbGF0ZXN0LmpzIj48L3NjcmlwdD4KICA8bGluayByZWw9InN0eWxlc2hlZXQi IGhyZWY9Imh0dHA6Ly9jb2RlLmpxdWVyeS5jb20vcXVuaXQvZ2l0L3F1bml0LmNzcyIgdHlwZT0i dGV4dC9jc3MiIG1lZGlhPSJzY3JlZW4iIC8+CiAgPHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFzY3Jp cHQiIHNyYz0iaHR0cDovL2NvZGUuanF1ZXJ5LmNvbS9xdW5pdC9naXQvcXVuaXQuanMiPjwvc2Ny aXB0PgoKICA8c2NyaXB0PgogICAgdmFyIGxvYyA9IHdpbmRvdy5sb2NhdGlvbjsKICAgIGZ1bmN0 aW9uIGdvdG9IYXNoKGZyYWcsIHJlcGxhY2UpIHsKICAgICAgaWYgKHJlcGxhY2UpIHsKICAgICAg ICBsb2MucmVwbGFjZShsb2MucGF0aG5hbWUgKyAobG9jLnNlYXJjaCB8fCAnJykgKyAnIycgKyBm cmFnKTsKICAgICAgfSBlbHNlIHsKICAgICAgICBsb2MuaGFzaCA9IGZyYWc7CiAgICAgIH0KICAg IH0KICAKICAgICQoZG9jdW1lbnQpLnJlYWR5KGZ1bmN0aW9uKCl7CiAgICAKICAgICAgdGVzdCgi Q2hhbmdpbmcgaGFzaCBhbmQgdGhlbiByZXBsYWNpbmcgdGhlIGhhc2ggKGFuZCBvdmVyIGFnYWlu KSB3aWxsIGRvZXMgbm90IGFkZCB0byBoaXN0b3J5IiwgZnVuY3Rpb24oKSB7CiAgICAgIAogICAg ICAgIGdvdG9IYXNoKCJzdGFydCIpOwogICAgICAgIGVxdWFsKGxvYy5oYXNoLCAiI3N0YXJ0Iiwg IkF0IHRoZSBzdGFydGluZyByb3V0ZSAoc28gd2Ugd29uJ3QgbGVhdmUgdGhlIHBhZ2UgZHVyaW5n IHRoZSB0ZXN0KSIpOwoKICAgICAgICBnb3RvSGFzaCgidG9CZVJlcGxhY2VkIik7CiAgICAgICAg ZXF1YWwobG9jLmhhc2gsICIjdG9CZVJlcGxhY2VkIiwgIkNoZWNrIHRoZSBmaXJzdCB0b0JlUmVw bGFjZWQgaGFzaCIpOwogICAgICAgIGdvdG9IYXNoKCJyZXBsYWNlMSIsIHRydWUpOwogICAgICAg IGVxdWFsKGxvYy5oYXNoLCAiI3JlcGxhY2UxIiwgIkNoZWNrIHRoZSByZXBsYWNlMSBoYXNoIik7 CgogICAgICAgIGdvdG9IYXNoKCJ0b0JlUmVwbGFjZWQiKTsKICAgICAgICBlcXVhbChsb2MuaGFz aCwgIiN0b0JlUmVwbGFjZWQiLCAiQ2hlY2sgdGhlIHNlY29uZCB0b0JlUmVwbGFjZWQgaGFzaCIp OwogICAgICAgIGdvdG9IYXNoKCJyZXBsYWNlMiIsIHRydWUpOwogICAgICAgIGVxdWFsKGxvYy5o YXNoLCAiI3JlcGxhY2UyIiwgIkNoZWNrIHRoZSByZXBsYWNlMiBoYXNoIik7CiAgICAgICAgCiAg ICAgICAgLy8gdGhpcyBpcyB0aGUgcHJvYmxlbSAtIHRoZSBsYXN0IG5vbi1yZXBsYWNlZCBoYXNo ICpzaG91bGQqIGJlIHJlcGxhY2UxIGFmdGVyIGJhY2sKICAgICAgICB3aW5kb3cuaGlzdG9yeS5i YWNrKCk7CiAgICAgICAgLy8gc2VlIG5leHQgdGVzdCBmb3IgdmFsaWRhdGlvbgogICAgICB9KTsK CgkgIHNldFRpbWVvdXQoZnVuY3Rpb24oKSB7CgkgIAoJICAgIHRlc3QoInBvc3QtcmVwbGFjZSBi cm93c2VyIGhpc3RvcnkiLCBmdW5jdGlvbigpIHsKCSAgICAJLy8gbWFrZSBzdXJlIHdlIGhhdmUg d2FpdGVkIGxvbmcgZW5vdWdoIGZvciB0aGUgbG9jIGhhc2ggY2hhbmdlCgkgICAgCW5vdEVxdWFs KGxvYy5oYXNoLCAiI3JlcGxhY2UyIiwgIlRoZSBoYXNoIHNob3VsZCBub3QgYmUgJyNyZXBsYWNl MicgYW55bW9yZSIpOwoJICAgIAoJICAgIAkvLyB3ZSBoYXZlIGdvbmUgYWxsIHRoZSB3YXkgYmFj ayB0byAjc3RhcnQgKGJ1dCBzaG91bGRuJ3QgaGF2ZSkKCQkJZXF1YWwobG9jLmhhc2gsICIjcmVw bGFjZTEiLCAiVGhlIGhhc2ggKnNob3VsZCogYmUgJyNyZXBsYWNlMScgYnV0IGlzIGFjdHVhbGx5 ICcjc3RhcnQnIik7CgkgICAgfSk7CgoJICB9LCAyMDApOwogICAgfSk7CiAgPC9zY3JpcHQ+CiAg CjwvaGVhZD4KPGJvZHk+CiAgPGgxIGlkPSJxdW5pdC1oZWFkZXIiPlFVbml0IGV4YW1wbGU8L2gx PgogIDxoMiBpZD0icXVuaXQtYmFubmVyIj48L2gyPgogIDxkaXYgaWQ9InF1bml0LXRlc3RydW5u ZXItdG9vbGJhciI+PC9kaXY+CiAgPGgyIGlkPSJxdW5pdC11c2VyQWdlbnQiPjwvaDI+CiAgPG9s IGlkPSJxdW5pdC10ZXN0cyI+PC9vbD4KICA8ZGl2IGlkPSJxdW5pdC1maXh0dXJlIj50ZXN0IG1h cmt1cCwgd2lsbCBiZSBoaWRkZW48L2Rpdj4KPC9ib2R5Pgo8L2h0bWw+Cg== 247033 2015-02-20 18:49:52 -0800 2015-02-24 19:38:17 -0800 history file_85881.txt text/plain 144 dawnelle.m.brice amF2YXNjcmlwdDpUVUlfdG9nZ2xlX2NsYXNzKCdhdHRhY2htZW50X3RleHRfZmllbGQnKTsgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBqYXZhc2NyaXB0OlRVSV90 b2dnbGVfY2xhc3MoJ2F0dGFjaG1lbnRfZGF0YScp