[whatwg] Firing popstate for all history entry changes

[Justin Lebar]

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

I think we've decided here that the time for major changes to this API
has past -- it's already in use in the wild.  If we *do* want to
change the API, I'd like to get in line.  :)

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

This is the model Firefox uses, and we're prepared to ship it in the
upcoming release of version 4.  It's divergent from WebKit, which has
already shipped, but WebKit is going to have to change anyway.
(http://webkit.org/b/41372)

-Justin

On Wed, Aug 25, 2010 at 2:55 PM, Mihai Parparita <mihaip at chromium.org> wrote:
> 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
>