18405 2012-07-25 17:35:47 +0000 History API: Clearly define popstate event behaviour on page load 2012-09-18 23:07:31 +0000 1 1 1 Unclassified WHATWG HTML unspecified PC All RESOLVED DUPLICATE 18605 http://www.whatwg.org/specs/web-apps/current-work/#traverse-the-history P2 normal Unsorted 1 joern.zaefferer ian ian mike contributor oldest_to_newest 71462 0 joern.zaefferer 2012-07-25 17:35:47 +0000 Currently the spec for the new history API (history.pushState and popstate event, http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html) is ambigous about when to trigger a popstate event, at least ambigous enough for Chrome/Safari and Firefox to differ in a severe way (from an API user perspective). The MDN article on popstate (https://developer.mozilla.org/en/DOM/window.onpopstate) puts it like this: "Browsers tend to handle the popstate event differently on page load. Chrome and Safari always emit a popstate event on page load, but Firefox doesn't." I'd like to see this clearly defined in the spec, so that users can use the API without requiring libraries like History.js (https://github.com/balupton/History.js/). Or custom workarounds like these: http://stackoverflow.com/questions/4688164/window-bind-popstate http://stackoverflow.com/questions/6421769/popstate-on-pages-load-in-chrome Or unreliable timeouts: http://dropshado.ws/post/15251622664/ignore-initial-popstate Considering the workarounds, the right behaviour seems to be the one as implemented in Firefox: Don't trigger popstate on page load, as that is a distinct event anyway. 74055 1 ian 2012-09-18 23:07:31 +0000 *** This bug has been marked as a duplicate of bug 18605 ***