- From: Mihai Parparita <mihaip@chromium.org>
- Date: Wed, 25 Aug 2010 14:55:26 -0700
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
Received on Wednesday, 25 August 2010 14:55:26 UTC