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/...
Depends on:
Reported: 2012-07-25 17:35 UTC by Jörn Zaefferer
Modified: 2012-09-18 23:07 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
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:
Or unreliable timeouts:

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 ***