[whatwg] history.popstate in Firefox4

Ian Hickson 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 mailing list