W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2011

[whatwg] history.popstate in Firefox4

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 7 Nov 2011 20:39:23 -0800
Message-ID: <CA+c2ei8cFRnfOPSU_OiHqbEsc7tRPiyhkH6Grk-XQ96SKAGe0w@mail.gmail.com>
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:
>
> ? http://hacks.mozilla.org/2011/03/history-api-changes-in-firefox-4/
>
> 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.)
>
> Test:
>
> ? http://damowmow.com/playground/tests/history/001.html
>
> It was made asynchronous here:
>
> ? http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-January/024871.html
>
> ...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.

/ Jonas
Received on Monday, 7 November 2011 20:39:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:09 UTC