statechage is triggered everytime pushState is called

[matteomelani]

Probably I am just very confused....

so in Firefox 6.0.1 everytime I call pushState the statechange event get fired. Is this the expected behavior?

How do you go about restoring the state of your page?

For example let's say I have page users/1/post_board, the page presents to the user a list of posts. Now the user can simply filter the post by clicking a button. The button does an ajax call to /users/1/post_board?author=john.
The app javascript invokes History.pushState() with a state object that contains all the info so that when the statechage event is triggered the page can be rebuilded. But since pushState trigger a statechage the page gets built twice.

What am I missing here?
Do you have any example of how this should work? I am sorry to say but the demo is pretty useless since there is not state rebuilding in it.

Thanks!

[JasonBerry]

Can't you just get the button to do the History.pushState() and then get the statechange event to manipulate the page content? I'm pretty sure that's how it's intended – and this way when the user clicks back/forward the statechange event will fire and manipulate the page content.

Hope that makes sense.

[matteomelani]

yes that is what I ended up doing.

-Matteo

On Thu, Sep 15, 2011 at 12:22 AM, Jason Berry <
reply@reply.github.com>wrote:

Can't you just get the button to do the History.pushState() and then get
the statechange event to manipulate the page content? I'm pretty sure that's
how it's intended – and this way when the user clicks back/forward the
statechange event will fire and manipulate the page content.

Reply to this email directly or view it on GitHub:
#96 (comment)

-Matteo

[dosena]

I have to second matteomelani's confusion.

Why does calling History.pushState() (or .replaceState()) trigger a 'popstate' event?

The "native" history.pushState() does not do this.

The 'popstate' is handled in History.onPopState, which then triggers a 'statechange' Event (line 1681, v 1.7.1).

I just want to push ... not have the thing popped right back at me.

[dermatthias]

Confusion here too. Sometimes I it's quite pratical to differentiate between pushing and poping a state.

[rroesler]

The documentation, the example, to reference to Ajaxify, all make it clear that statechange gets call on every state change. And the promoted pattern is to change your code to actions call pushstate which causes a statechange which (should) invoke the actual action.

But, wow, does this cause a lot of extra effort when authoring the solution.

I'm using unobtrusive Ajax and my links of tons of data-* attributes to drive the actual partial page refresh, highlight menu entries, run back ground actions (initializations, "welcome popups"), etc.

With History.js I have ended up with a lot of duplicated actions, A user visible action that calls pushState and a hidden action that does the actual work. I also ended up almost duplication the state so that I could handle back/forward vs new action properly.

And my stateChanged event handler has become very complex as I attempt to match states to the hidden actions.

At least one whole layer of this could go away if stateChange told me whether the change was a back/forward button push or a pushState/replaceState/original navigational. Things which the code is doing now in its popState event handler.

I'm currently in optimization mode, and looking to possible replace History.js (or modify it) so the application code can be simplified into something that someone else might be able to follow.

[rroesler]

I modify my copy to better match W3C popState event semantics (I think) .. we are testing in our application now.

See issue 137

[pysis]

@rroesler can u share your version

[rroesler]

Can you read branch/fork "rroesler / history.js" .. I updated my change this morning.

Otherwise email me at rroesler@kinetekscorp.com

[miracle2k]

By all means, provide an event that triggers whenever pushState() is called, to allow for the current workflow.

However, there should also be an event that reacts only to actual browser navigation. There is a reason the spec was designed as it is. Forcing the actual content load to be done through the statechange event is a flawed approach, and makes all kinds of things more complicated.

The fix by @rroesler may be the wrong solution to this. It supresses the statechange event, but popstate is still artificially triggered. Instead, maybe continue to trigger statechange on pushState(), and let popstate only trigger when there is an actual pop taking place.

[evil-shrike]

I also can't understand History.js behavior. All provided samples are pretty useless.

History.js give us two events: popstate and statechange. popstate is from History API spec - https://developer.mozilla.org/en/DOM/window.onpopstate. But why do we need statechange event? Anyway both events fire in the same conditions: when any change happens.

But obviously any app has two workflows:

• when an app changes its state and just wants to track this change in the history
• when a user change app's state via back/forward or direct url navigation

These cases should not be treated in the same way as it now happens.

UPDATE:
HTML spec doesn't state that popstate event should be raised on pushState: http://www.whatwg.org/specs/web-apps/current-work/#history-0
Also not firing popstate event on call History.pushState method is expected by many people - see http://diveintohtml5.info/history.html

[rxaviers]

Confused++

Specification [1] [2] states that:
"just calling history.pushState() or history.replaceState() won't trigger a popstate event".

History.js aims to "overcome the cross-browser compatibility", and it's been doing a great job. Sometimes, it's hard to strictly follow the specs. But, in my opinion this issue is a core behavior for the history manipulation. Going against the specs here should not be a by-design thing. One possible solution would be having an event (a) to behave the way popstate should, and having an event (b) to behave the currently-always-triggered-way.

I strongly encourage History.js to re-think about it.

[cphoover]

Anyone have a fork of history.js designed more in alignment with the w3c spec?

[emmanuel]

First, thanks for building and sharing History.js.

I don't really have much to add to this discussion, but I wanted to add a +1 for not firing popstate on pushState/replaceState.

Unfortunately, History.js, while laudable, is useless for me because of this behavior. See here for a little more about why.

[sgentile]

I also want to request the same - I came to History.js to support IE9 back button support (I'm using popstate)

+1 for not firing popstate on pushState/replaceState please!

[pixeldrew]

+I third this.

To handle this flow, I have to wait for the pushstate event to fire before I can follow through with application logic. Waiting for this event makes things harder to follow and more importantly goes against the W3C spec.

This shouldn't be called a shim for the HTML5 History spec, if by design it isn't following the spec. Since most likely this has become the norm for people who have implemented History.js I suggest a conditional option that isn't by default set.