Bug 142151

Summary: history.replaceState/location.replace incorrectly adds new entries to global history in Safari
Product: WebKit Reporter: Jason Davies <jason.davies>
Component: Page LoadingAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: beidson
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   

Description Jason Davies 2015-03-01 10:57:34 PST
The purpose of history.replaceState is to *modify* the current history entry.  This works in the context of using the back button.

However, it always seems to add *new* history entries, in the context of the History menu item (and "Show History" page).

This causes a huge number of history entries for pages that update the URL frequently, e.g. zoom/pan of maps where the current zoom and position are encoded in the URL.

A good example of this in the wild is http://polymaps.org/ - e.g. http://polymaps.org/ex/midnight-commander.html - note that Polymaps actually uses location.replace internally with the same problem, though using history.replaceState doesn't fix it.
Comment 1 Jason Davies 2015-03-01 11:11:06 PST
Interestingly, Chrome appears to have the same behaviour for history.replaceState (adding new entries to the history page) - but not for location.replace.
Comment 2 Brady Eidson 2015-03-03 22:03:30 PST
The specs declare when the browser engine has to do with the session history, which is what is represented by the back button. And WebKit handles that correctly.

I don't believe any spec defines what browsers have to do with their global history collections, as that's outside the scope of the engine.

So I think you're reporting a Safari bug, as Safari decides what entires to show in its history menu. And Safari is not WebKit.