[whatwg] Onpopstate is Flawed

[Justin Lebar]

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

-Justin

[1] Patch v4: https://bugzilla.mozilla.org/show_bug.cgi?id=615501

On Mon, Feb 7, 2011 at 5:07 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> 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
>