[Webkit-unassigned] [Bug 59195] New: location.replace doesn't update hash in browser history

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=59195

           Summary: location.replace doesn't update hash in browser
                    history
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: Windows XP
            Status: UNCONFIRMED
          Severity: Major
          Priority: P2
         Component: History
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: jarol1 at seznam.cz
                CC: jarol1 at seznam.cz


Created an attachment (id=90697)
 --> (https://bugs.webkit.org/attachment.cgi?id=90697&action=review)
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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.