[whatwg] history.popstate in Firefox4

[Ian Hickson]

On Mon, 7 Nov 2011, Jonas Sicking 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.

The way this ended up being specced is that the event is synchronous with 
traversal, but the events are all fired at the end, so it doesn't need to 
block either process, and history.back() itself is done async so it never 
blocks on that call at all.

I believe this makes things ok for everyone, but this is a particularly 
hairy part of the platform... hopefully nobody finds any more problems.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'