[whatwg] Onpopstate is Flawed

[Jonas Sicking]

On Sun, Feb 6, 2011 at 10:18 AM, Justin Lebar <justin.lebar at gmail.com> wrote:
>> 1) 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.
>>
>> Proposal B has the advantage of requiring fewer changes.
>
> The more I think about this, the more I like this option.  It's a
> smaller change than option A (though again, we certainly could expose
> the state object through a DOM property separately from this
> proposal), and I think it would be sufficient to fix some sites which
> are currently broken.  (For instance, I've gotten Facebook to receive
> stale popstates and show me the wrong page just by clicking around
> quickly.)
>
> Furthermore, this avoids the edge case in option B of "you don't get a
> popstate on the initial initial load, but you do get a popstate if
> you're reloading from far enough back in the session history, or after
> a session restore."

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. So if you're
reloading from session restore or if you're going far back enough in
history that you end up parsing a Document, you never get a popstate.

You get a popstate when and only when you transition between two
history entries while remaining on the same Document.

So the basic code flow would be:

Whenever creating a part of the UI (for example during page load or if
called upon to render a new AJAX page), use document.currentState to
decide what state to render.
Whenever you receive a popstate, rerender UI as described by the popstate.

So no edge cases that I can think of?

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.

> I was concerned that pages might become confused when they don't get a
> popstate they were expecting -- for instance, if you pushState before
> the initial popstate, a page may never see a popstate event -- but I
> think this might not be such a big deal.  A call to push/replaceState
> would almost certainly be accompanied by code updating the DOM to the
> new state.  Popstate's main purpose is to tell me to update the DOM,
> so I don't think I'd be missing much by not getting it in that case.

That was my thinking too FWIW.

/ Jonas