This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 18405 - History API: Clearly define popstate event behaviour on page load
Summary: History API: Clearly define popstate event behaviour on page load
Status: RESOLVED DUPLICATE of bug 18605
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-25 17:35 UTC by Jörn Zaefferer
Modified: 2012-09-18 23:07 UTC (History)
2 users (show)

See Also:


Attachments

Description Jörn Zaefferer 2012-07-25 17:35:47 UTC
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.
Comment 1 Ian 'Hixie' Hickson 2012-09-18 23:07:31 UTC

*** This bug has been marked as a duplicate of bug 18605 ***