59195 2011-04-22 06:06:18 -0700 location.replace doesn't update hash in browser history 2011-06-30 18:27:50 -0700 1 1 1 Unclassified WebKit History 528+ (Nightly build) PC Windows XP RESOLVED DUPLICATE 63777 P2 Major --- 0 jarol1 webkit-unassigned beidson fishd jarol1 mihaip oldest_to_newest 390738 0 90697 jarol1 2011-04-22 06:06:18 -0700 Created attachment 90697 sample to demonstrate history behaviour In RIA applications built on GWT (but also elsewhere) it is common to keep state by saving some value after # in URL. This is done by window.location.hash = "appPlace;param1=value1"; - and results in creation of new browser history item. But sometimes location in the application doesn't change (user remains on the page but does something), only some parameters in hash need to be updated to enable user bookmark the correct location or be able to send a correct link to friend. For update, we don't want to create new history item by assigning new value to window.location.hash. A common solution is to use window.location.replace(newUrl);, where we ensure that the "newUrl" value has the same base Url, only # value is different. Current behaviour in the latest Chrome and Safari (tested on WebKit-r84564) is that window.location.replace changes current URL, but doesn't update current history item in browser history. This then leads to a problem if we perform window.location.replace followed by creation of new history item via window.location.hash. When user hits back browser button, he won't return to the updated URL, but to the original one. In Internet Explorer 8, 9, Firefox 3.0, Firefox 3.6, Firefox 4 invocation of window.location.replace also updates current browser history item. For IE 7 there is a solution with writing to iframe with 'replace' flag. It would be nice if WebKit also behaved in this way to better support stateful RIA applications. I attached slightly stripped closure_library which includes a nice demo for history testing - closure\goog\demos\history1.html. I modified the library history.js file to set location.hash instead of location.href for creating new history item. The following use cases should be tested: 1.) Update of history item followed by creation of new history item 1.1) Type token "aaa", click on SetToken 1.2) Type token "bbb", click on SetToken 1.3) Type token "bbb2", click on Replace Current Token 1.4) Type token "ccc", click on SetToken 1.5) Hit back browser button After step 1.5, we will see "#bbb", but we would like to see "#bbb2". This is like above mentioned versions of IE and Firefox behave. 2.) Update of old history item (reload page for this test) 2.1) Type token "aaa", click on SetToken 2.2) Type token "bbb", click on SetToken 2.3) Type token "ccc", click on SetToken 2.4) Hit back browser button, you should see "#bbb" 2.5) Type token "bbb2", click on Replace Current Token 2.6) Hit forward browser button and then back browser button After step 2.6, we will see "#bbb", but we would like to see "#bbb2". This is like above mentioned versions of IE and Firefox behave. There are other reported bugs related to location.replace, but in the latest releases it seems that location.replace doesn't break history. 390849 1 mihaip 2011-04-22 10:03:33 -0700 I'm on a plane, so I can't look at the attached test case (something smaller than 3.2 MB would be appreciated), but bug 57979 is most likely related to this (it's also about location replacement not updating the current history entry). 430920 2 mihaip 2011-06-30 18:27:50 -0700 *** This bug has been marked as a duplicate of bug 63777 *** 90697 2011-04-22 06:06:18 -0700 2011-04-22 06:06:18 -0700 sample to demonstrate history behaviour closure_library.zip application/zip 0 jarol1