142151 2015-03-01 10:57:34 -0800 history.replaceState/location.replace incorrectly adds new entries to global history in Safari 2017-01-18 23:39:14 -0800 1 1 1 Unclassified WebKit Page Loading 528+ (Nightly build) Unspecified Unspecified NEW P2 Normal --- 1 jason.davies webkit-unassigned beidson oldest_to_newest 1073171 0 jason.davies 2015-03-01 10:57:34 -0800 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. 1073175 1 jason.davies 2015-03-01 11:11:06 -0800 Interestingly, Chrome appears to have the same behaviour for history.replaceState (adding new entries to the history page) - but not for location.replace. 1073983 2 beidson 2015-03-03 22:03:30 -0800 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.