HTML5 now fires the hashchange event synchronously, and we probably should change our implementation to match this. See http://www.whatwg.org/specs/web-apps/current-work/#history-traversal

So why synchronously? I thought IE dispatches async.

IE does dispatch async; in fact the spec was originally changed to match this behavior. Hixie decided to change it back in this message to the list [1]. I think it basically boils down to the following case: Visit page, page#a, page#b. Go back twice, quickly. You'll get two hashchange events because the hash changed twice, but if you went back quickly enough, location.hash will be '#' for both those events, and so it's difficult for the app to determine that you went through state '#a' before reaching '#'. I think we were willing to accept this before we started thinking about popstate, which might be even more confusing if it was dispatched while you were at the wrong page. [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022312.html

Would it make sense if hashchange event had attribute DOMString hash; (I need to now remember what problems sync hashchange causes.)

Maybe. But then you have the same problem as async popstate -- now the state/hash argument doesn't match the current location. There might be other problems, too. :)

Patch to make hashchange synchronous.

Olli: is it really safe to run scripts here?

As far as I see it should be. Or at least it shouldn't be any more scary than beforeunload. But Justin, perhaps you could add an assertion to DispatchSyncHashchange to check that it is safe to run scripts.

Don't we already have such an assertion in the event-dispatch code? If not, we should.

It doesn't appear that we call nsContentUtils::IsSafeToRunScripts from anywhere deep in the event dispatching code. I've added the check here and filed a follow-up at bug 531176.

I check this patch in, but backed it out since it seemed to cause a failure in test_bug509055.html: http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1262828244.1262829317.1880.gz

Fixed the failing test.

Should update https://developer.mozilla.org/en/DOM/window.onhashchange when this lands. It's a bit unfortunate that 3.6's behavior will be different from the newer versions..

Documentation updated: https://developer.mozilla.org/en/DOM/window.onhashchange

And now it seems that Hixie wants it to be async again :( http://html5.org/tools/web-apps-tracker?from=4631&to=4632

Yeah, sorry about that. I try to minimise churn, but sometimes I make mistakes. :-(

Should this be backed out?

Seems like HTML5's session history handling isn't stable at all atm. There are certainly still open issues and those may affect to the recent change which made back()/forward() async (I may not agree with the change, certainly the reasoning for the change isn't good enough), and caused also hashchange event to become async again.

Yeah, this stuff is very new (hasn't ever been specced before, so we're finding all kinds of issues with it). It would probably make sense to wait a few months and see how it settles out. Again, sorry about the churn.

For what it's worth, the sync behavior breaks at least one site (dominos.com) as of a few days ago when they redesigned, presumably because they assumed the de-facto-standard async behavior. So I think we do want async behavior here. See bug 615061.

(In reply to comment #16) > Documentation updated: > https://developer.mozilla.org/en/DOM/window.onhashchange Bug 615061 is fixed, I took back that updates