[whatwg] Onpopstate is Flawed

[Justin Lebar]

> 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.

Yeah, I think it's too late to move to this approach.

> 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?

I agree it's potentially misinformative to give the page a popstate in
this case.  But it's possible that a page might be built so that it
doesn't begin to function properly until it receives the initial
popstate.  If a user clicks on a link and causes a replaceState call
before the initial popstate, then such a page could break.

It's an edge case, but that's exactly why it concerns me -- nobody's
going to test to make sure that their page works properly if the
initial popstate is canceled by a push/replaceState.

> 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.

Oh, is this why we needed the initial popstate?  For instance, we
persist state objects across session restore, so when the user
restarts, a page could get an onload followed by a popstate with a
non-null state object.

[Aside: What we currently have doesn't work well for this case, since
the page really needs the state object at the moment it starts to run
script so it can decide what content to load, but it doesn't get the
state object until after onload.]

If we can't get rid of the initial popstate because of the above, then
I think what Jonas proposed is reasonable.  I just wish we had
something with fewer gotchas.

-Justin

On Wed, Feb 2, 2011 at 2:15 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> 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
>