[whatwg] history.popstate in Firefox4

[Justin Lebar]

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