[whatwg] history.popstate in Firefox4
ian at hixie.ch
Wed Mar 23 17:37:14 PDT 2011
I'm studying some of the feedback raised over the past few months
regarding history.pushState() and related APIs, in particular in the
context of applying these changes to the spec:
One of the differences between the spec and the API as implemented in
Firefox that is not mentioned in the post above seems to be that the
firing of 'popstate' events during history.back() is synchronous in
Firefox, but asynchronous in the spec. (Chrome implements it in an
asynchronous manner as per the spec. I couldn't test Safari.)
It was made asynchronous here:
...specifically, to make it possible to implement history traversal in a
multiproces UA without requiring a blocking call across the process
boundary (assuming each top-level Document in a tab's history is in a
different process, and that they are coordinated by yet another process).
Making it async with the proposed changes leaves a race condition between
the user hitting the back button and a pushState() around the same time,
but in practice that seems somewhat unlikely since usually pushState() is
done in response to user input. (We could also block the event if we
detect it's no longer consistent with the current state, but that would
mean hitting back twice in a row would only fire one "back" event, which
seems dodgy also.)
Would keeping 'popstate' async, without dropping any events, be ok with
Gecko? (I've gotten an ok from Safari, Chrome, and Opera to make the
changes described in the blog post above, and currenty plan to do those.
I'm not aware of any other implementations of this API.)
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg