[whatwg] history.popstate in Firefox4
jonas at sicking.cc
Mon Nov 7 20:39:23 PST 2011
On Wed, Mar 23, 2011 at 5:37 PM, Ian Hickson <ian at hixie.ch> wrote:
> 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.)
What was the outcome here? I suspect that we'd like to keep it sync in
Firefox, but I haven't really thought through the implications.
CC'ing some people that have worked on history traversal for Gecko.
More information about the whatwg