Re: [whatwg] history.popstate in Firefox4
On Mon, 7 Nov 2011, Jonas Sicking wrote: > On Wed, Mar 23, 2011 at 5:37 PM, Ian Hickson 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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] history.popstate in Firefox4
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 wrote: > On Wed, Mar 23, 2011 at 5:37 PM, Ian Hickson 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
Re: [whatwg] history.popstate in Firefox4
On Wed, Mar 23, 2011 at 5:37 PM, Ian Hickson 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
[whatwg] history.popstate in Firefox4
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.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
