[whatwg] Onpopstate is Flawed

On Fri, Feb 11, 2011 at 12:25 AM, Justin Lebar <justin.lebar at gmail.com> wrote:
>> I'm not sure I follow you here. My idea for option A is that you never
>> get a popstate when doing the initial parsing of a page.
>
> Okay, I may still have misunderstood, despite my best efforts! ?:)
>
>> Option B:
>> Fire popstates as we currently do, with the caveat that you never
>> fire a stale popstate -- that is, if any navigations or
>> push/replaceStates have occurred since you queued the task to fire the
>> popstate, don't fire it.
>
> Is my option B clear? ?It's also what the patch I have [1] does.
>
> We'd might want to make popstate sync again, since otherwise you have
> to schedule a task which synchronously checks if no state changes have
> occurred, and dispatches popstate only if appropriate.
> I know Olli has some thoughts on making popstate sync, and fwiw, FF
> currently dispatches it synchronously.
>
>> The main problem with this proposal is that it's a big change from
>> what the API is today. However it's only a change in the situation
>> when the spec today calls for firing popstate during the initial page
>> load. Something that it seems like pages don't deal with properly
>> today anyway, at least in the case of facebook.
>
> Given the adoption the feature has seen, I guess I'd favor a smaller
> change. ?In particular, the option B above makes it possible to write
> correct pages without ever reading the DOM "current state" property --
> it's there only as an optimization to allow pages to set their state
> faster, so no rush to put it in Right Away. ?In contrast, a correct
> page with option A would have to check its state at some point as it
> loads.
>
> I guess I don't see why it's better to make a big change than a small
> one, if they both work equally well.

The problem with option B is that pages can't display correctly until
the load event fires, which can be quite late in the game what with
slow loading images and ads. It means that if you're on a page which
uses state, and reload the page, you'll first see the page in a
state-less mode while it's loading, and at some point later (generally
when the last image finishes loading) it'll "snap" to be in the state
it was when you pressed reload.

You'll get the same behavior going back to a state-using page which
has been kicked out of the fast-cache.

/ Jonas

Received on Friday, 11 February 2011 12:09:10 UTC