[whatwg] Onpopstate is Flawed

[Jonas Sicking]

On Wed, Feb 2, 2011 at 2:34 PM, Justin Lebar <justin.lebar at gmail.com> wrote:
>> 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.

Even if we also include the new state in the popstate events? Such a
change seems mostly additive to the current spec.

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

But with my suggested change, pages have no reason to wait until the
initial popstate fires. And in fact they can't since we don't fire it
at all :) But yes, I agree that it could break already existing pages
that have the above behavior.

So the question is if webkit would be ok with such a change.

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

I think my latest proposed change makes this a whole lot better since
the state is immediately available to scripts. The problem with only
sticking the state in an event is that there is really no good point
to fire the event. The later you fire it the longer it takes before
the page works properly. The sooner you fire it the bigger risk you
run that some script runs too late to get be able to catch the event.

/ Jonas