W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2010

[whatwg] Firing popstate for all history entry changes

From: Mihai Parparita <mihaip@chromium.org>
Date: Wed, 25 Aug 2010 14:55:26 -0700
Message-ID: <AANLkTik-xgNdcyHZ8R-eeFuvueb-EmBC_bKDq8MbO+U2@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:00 UTC