17155 2012-05-23 09:53:34 +0000 The "navigating to a fragment identifier" algorithm shouldn't be async 2013-04-22 18:01:59 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#scroll-to-fragid P3 normal Needs Research 1 james ian ian mike contributor oldest_to_newest 68040 0 james 2012-05-23 09:53:34 +0000 When UAs navigate to fragment identifiers they seem to do it in a sync way i.e. location.hash = "#bar" //location.hash is now "#bar" However the hashchange event seems to be queued rather than fired synchronously so that location.hash = "foo" onhashchange = function(e) {document.body.innerHTML += "<p> " + e.oldURL + " " + e.newURL} location.hash = "bar" causes the event to be fired twice. For other navigations, the async behaviour seems to be correct. 68042 1 james 2012-05-23 10:01:30 +0000 Also, the scrolling seems to happen synchronously 70823 2 contributor 2012-07-18 17:33:57 +0000 This bug was cloned to create bug 18178 as part of operation convergence. 71734 3 james 2012-08-01 11:26:46 +0000 And the popstate event is async. 77368 4 ian 2012-10-30 00:25:08 +0000 There seem to be multiple bugs here. Do you have some test cases? Are things like pending history.back() calls aborted as well? Is the new session history entry added synchronously or asynchronously? (Might be able to tell by judicious use of back()/forwards() after the setter is invoked.) I guess the "Traverse the History" algorithm needs to be given a flag to decide whether the events are sync or async? That's unfortunate. Are the events synchronous in the same task? Or two different tasks? 86487 5 contributor 2013-04-22 18:01:59 +0000 Checked in as WHATWG revision r7846. Check-in comment: Try to match reality better for dynamic location.hash navigation. http://html5.org/tools/web-apps-tracker?from=7845&to=7846