There's been some discussion on http://webkit.org/b/41372 about
Gecko's vs. WebKit's implementation of the popstate event. It turns
out that a careful reading of
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#history-traversal,
specifically of item 10, indicates that if you have this sequence of
steps:
1. Go to a page
2. Change the location's fragment to #step1
3. Change the location's fragment to #step2
4. Go back
5. Go back
Then popstate should be fired after every step, except for step 4
(test case at https://bugs.webkit.org/attachment.cgi?id=65467). That's
because in step 4 we're going back from one history entry without a
state object to another without a state object, and the target entry
is not the first one for the document either.
However, it seems like the (web) developer's mental model for popstate
would be much simpler if it fired whenever the current session history
entry changed, regardless of whether it has a state object or was the
first entry. Then if someone wished to listen to all history events,
they would just have to use onpopstate, instead of a combination of
onpopstate and onhashchange.
It might also help if the event wasn't called "popstate", since that
implies a 1:1 relationship with pushState calls, but you can already
get popstate events without corresponding pushState calls.
"historytraversal" perhaps?
Mihai