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

[whatwg] history.popstate in Firefox4

From: Justin Lebar <jlebar@mozilla.com>
Date: Wed, 21 Dec 2011 12:26:10 -0500
Message-ID: <CAFWcpZ6hHyS0yrFf8ezCcnDDnbZKa6uCFfj3WuTXK548R9OgqA@mail.gmail.com>
Hixie's explanation of why the event should be sync makes sense to me.

I recall that Olli had an objection other than this race condition,
but now I can't find the e-mail!

On Mon, Nov 7, 2011 at 11:39 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> 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 Wednesday, 21 December 2011 09:26:10 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:38 UTC