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 Loading | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | beidson |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Jason Davies
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.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Jason Davies
Interestingly, Chrome appears to have the same behaviour for history.replaceState (adding new entries to the history page) - but not for location.replace.
Brady Eidson
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.