- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 2 Feb 2011 14:15:14 -0800
On Wed, Feb 2, 2011 at 2:05 PM, Justin Lebar <justin.lebar at gmail.com> wrote: > I'm a bit uncomfortable with this behavior, since it seems that having > replaceState cancel the initial popstate is at least somewhat > surprising. > > How is this better than never firing an initial popstate? My thinking was that if someone calls replaceState, then probably that means that they're currently changing the page to represent that new state. If they do that then I don't see that they initial popstate would help them in any way? Yet another solution would be to always expose the current state through a member on the window or the document. Then popstate would represent any transition in the current state and wouldn't be needed for the initial page load. So during loading, any script that wants to know what the initial (or current) state is does not need to wait for the first popstate, but can simply grab the state and go. The main problem I can think of with this design, apart from it being a bigger change from what we've got, is what happens if someone modifies the current-state member on the window/document. While we can make the member read-only, that doesn't help if the state is a deep object hierarchy. In IndexedDB we decided to not attempt to solve the problem and instead rely on authors not to trigger the footgun. / Jonas
Received on Wednesday, 2 February 2011 14:15:14 UTC