This is maybe not a bug, but the specs indicates that the documents URL should change when pushState is called and it seems strange to not reflect this in the UI as well. "The document's address is an absolute URL that is set when the Document is created. The document's current address is an absolute URL that can change during the lifetime of the Document, for example when the user navigates to a fragment identifier on the page or when the pushState() method is called with a new URL." http://www.whatwg.org/specs/web-apps/current-work/#documents Both Minefield and Chromium change the URL in the address bar when pushState is used. A important use case for this feature would be if content is loaded with ajax and the user would like to use the URL in the address for tipping about this specific content.
Chrome and Minefield have the advantage of having released a new browser client in addition to their engine changes that implement replaceState. WebKit implements the callback for client apps in WebFrameLoaderClient.mm: void WebFrameLoaderClient::dispatchDidReplaceStateWithinPage() But currently shipping Safari doesn't listen for it for obvious reasons. (it doesn't ship with a WebKit that supports the feature) This bugzilla is still interesting, however, because DRT should listen for both the push and replace state callbacks and dump them out, so we can at least have layouttest coverage.
Chrome does not yet update the address bar: http://code.google.com/p/chromium/issues/detail?id=36548
Should this bug still be open? Both Chrome and Safari now update the location bar.
The original report is not about anything in open source WebKit. But Brady suggested repurposing it for DumpRenderTree improvement, which makes sense to me.