HTML5 pushState triggers path dispatch for initial page load about pathjs HOT 24 CLOSED

Michel, I'll take a look into this as soon as possible, as it's a pretty glaring bug. I had no idea this was happening, and should have tested more thoroughly. Thanks for pointing this out. I hope you can continue to use PathJS in the interim.

from pathjs.

Definitely. It's easy to work around anyway. I actually like Path.js a
lot. It's a very simple but elegant implementation. I would take a
stab at this myself, but I am not yet familiar enough with JavaScript
or the library to really do a good job, hence the bug report :)

Sent from my iPhone

On 9 Dec 2011, at 03:44, Mike Trpcic
[email protected]
wrote:

Michel, I'll take a look into this as soon as possible, as it's a pretty glaring bug. I had no idea this was happening, and should have tested more thoroughly. Thanks for pointing this out. I hope you can continue to use PathJS in the interim.

---

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

from pathjs.

I just looked into this issue and was not able to reproduce with the code supplied above. My test case and outcome is documented here. Before I can look further into the bug, I'll need to see it in action. Could you please provide a link to a hosted instance of this bug so I can take a look?

If no information is given in about a week, I'll assume that you figured out the problem (and that it was on your end, not a problem with PathJS), I'll close the issue as resolved.

Thanks,

-Mike

from pathjs.

I will take a look and if I cannot figure it out, I will try to send
you a more complete test case :)

from pathjs.

I think that this issue is only appearing at Google Chrome browser.

In firefox if I visit an URL with a fullpath, for example: http//www.mypage.com/profile/1 the page loads only once. But in google chrome the page is rendered and then rendered again.

It's problematic if you are loading, for example, twitter and facebook buttons since you have to reprocess the Javascript again.

Are you able to reproduce it in Google Chrome? Can I help in some way?

Best regards

from pathjs.

I will attempt to reproduce this next time I get an opportunity. It would be extremely helpful if somebody could put together a piece of example code in a Gist that is known to cause the issue, as well as details on the browser(s) that it's encountered in (Browser, version, etc).

from pathjs.

It's difficult to prepare a test case. The problem appears when you are visiting an URL that support JS and DIRECT access:

I'm coding a Ruby on Rails App, and my app admits visiting "every single URL" directly or using links from the app (rendering whit html or JS).

If you visit an URL directly from firefox, everyting is ok, but if you visit an URL with Chrome it renders first, and then attempts to reload using the JS approach.

Here is an example of a HTML Only Page in my App:

http://www.beperk.com/innovators

If you visit it with firefox it reders once. But if you visit it with chrome you will see the HTML render and then the JS error Alert when it tries to render the JS version (Using Google Chrome 16.0.912.75 on Mac OS X 10.7.2)

Is this example enought? I'll try to do my best to help you.

Thanks a lot!

from pathjs.

I've discovered the problem. Webkit ALWAYS fires a popstate() after the load() event.
http://hacks.mozilla.org/2011/03/history-api-changes-in-firefox-4/

http://stackoverflow.com/questions/4688164/window-bind-popstate

So, when a page is loaded in Google Chrome it always fires a JS call with pathJS

from pathjs.

Check here:
https://github.com/defunkt/jquery-pjax/blob/master/jquery.pjax.js

The block talking about:
/ Used to detect initial (useless) popstate.
// If history.state exists, assume browser isn't going to fire initial popstate.
var popped = ('state' in window.history), initialURL = location.href

// popstate handler takes care of the back and forward buttons
//...........
...........

from pathjs.

Thanks dolarsrg for doing the sleuth work for me! I'll get this fixed as soon as I get my development environment set up in my new virtual machine. It should be fairly quick.

from pathjs.

No problem! Glad to help.

Let me know if you need more details.

Regards.

from pathjs.

Same problem here. Looking forward to a fix and work-around in the interim. I definitely want to use the routing I've set up with pathjs on load, but need the behavior to be consistent.

from pathjs.

Curious when this will be fixed? Just started integrating Path.js in a project and immediately ran into this.

On a side note, how should we be defining default views like Backbone.js History? Should be able to define a route as either '/' or '' and have it work as though a full path is there.

from pathjs.

geuis,

This does the trick for me - dispatching an event on load regardless of browser, and running the default route if rescue is triggered:

var pathname;

Path.map("/").to(function(){
  if (pathname != '/') {
    pathname = '/';
    //handle default route
  }
});

Path.rescue(function(){
  console.error("Route Not Found", Path.routes.current);
  if (!Path.history.supported) {
    //handle default route - don't dispatch '/' here
  }
});

Path.history.listen(true);

if (Path.history.supported) {
  var popped = ('state' in window.history);
  if (popped) {
    Path.dispatch(document.location.pathname);
  }
} else {
  if (!document.location.hash) {
    Path.dispatch('/');
  }
}

You'll need to set pathname in your other routing handlers. The variable is there to avoid running the default route twice in certain instances.

pathname = Path.routes.current;

I'm not advocating this solution. Path should handle the browser differences internally and provide consistant event triggering so code like this is unnecessary. This is just what is working for me now across IE8 and the latest Firefox, Safari and Chrome.

from pathjs.

Thanks for the info. I did a similar hacky version of just doing one pushState after Path.history.listen(true); Has a couple of drawbacks but works for now.

from pathjs.

I'm getting this initial pop behavior in Chrome as well, but when I run

('state' in window.history)

It returns true in BOTH Chrome and Firefox, so I cannot detect it... In Chrome 19 developer (I'm about to downgrade to stable and see if this behavior still exists).

from pathjs.

Update: Chrome stable works fine, just developer seems to be broken.

from pathjs.

That's odd, because I'm in Chrome 17.0.963.56 and in the console, window.history.state is undefined.

from pathjs.

Yes on 17 I get window.history.state undefined (so false for 'state' in window.history). On Chrome developer (19) I was getting true.

from pathjs.

This has been fixed as of PathJS version 0.8.3 (committed just now). Let me know if there are any further issues with the dreaded "initial popState". I sincerely apologize that this took this long to fix.

from pathjs.

Thanks Mike,

We found that users with older versions of Safari/WebKit that are supposed to support history, do not handle popState correctly. While I would have liked to offer a solution in PathJS applied over 0.8.3, I ended up doing the user-agent check and event dispatch in my site's main js to get the fix out quickly. I hope the info helps others that encounter the issue and maybe inspire a fix in PathJS:

#22

from pathjs.

This is broken again in Chrome 19, Chrome now has a history.state attribute, but it still fires onpopstate on page load.

We had to resort to special-casing webkit.

http://code.google.com/p/chromium/issues/detail?id=63040

from pathjs.

also had that issue in chrome 19. our workaround:

$(function() {
  var __listen = Path.history.listen;
  Path.history.listen = function(fallback) {
    __listen(fallback);
    if ($.browser.webkit && parseFloat($.browser.version) >= 536.5) {
     Path.history.initial.popped = false;
    }
  };
  Path.history.listen(true);
});

from pathjs.

Having same problem in lastest Chrome.

from pathjs.