Is it possible to detect the hashchange only on a browser history change (i.e. Back or Forward button)?

I have seen the onBeforeUnload event, but this event does not fire on hash change, as the window is not unloading.

The hashchange event obviously fires anytime the hash changes. Any fix? Preferably without a plugin. I have seen the jQuery history plugin, but am looking for the simplest solution.

Thanks for the help.

Is it possible to detect the hashchange only on a browser history change (i.e. Back or Forward button)?

I have seen the onBeforeUnload event, but this event does not fire on hash change, as the window is not unloading.

The hashchange event obviously fires anytime the hash changes. Any fix? Preferably without a plugin. I have seen the jQuery history plugin, but am looking for the simplest solution.

Thanks for the help.

• javascript
• jquery
• back
• browser-history
• hashchange

5 Answers 5

I ended up marking a flag whenever my navigation was triggered, and if the flag was marked, the hashChange event would ignore it, otherwise it would handle it as if it was a back/forward event.

Take a look at the window.onhashchange event.

It is not currently supported in all browsers however. Take a look at the BA jQuery Hash Change Plugin here. It may work, if you choose to use a plugin in the end.

I hope this helps!

What I think Chris was asking is for a way for the window.onhashchange event to work only when you are navigating through browser history (back/forward) buttons.

Answer = No... but you can put an if statment in the function.
I would do this:

$('.nav').click(function() {    //on the onclick event for your nav add a class
  $(this).addClass('navClick'); // before you change the hash.
  window.location.hash = 'state' + $(this).html();
});
function getLocationHash() {
  return window.location.hash.substring(1);
}
window.onhashchange = function(e) { // if element does not exist with your
  if ($('.navClick').length == 0) { // 'navClick' class then check hash
    switch(getLocationHash()) {
      case 'state1': 
        execute code block 1;
        break;
      case 'state2':
        execute code block 2;
        break;
      default: 
        code to be executed if different from case 1 and 2;
    }
  } else {                         // removes the class if it does
    $('.navClick').removeClass('navClick');
  }
};

I did something similar on my site

It is all dynamically changing content. I still use the window.location.hash to keep track of the site states. If you navigate through the site and then begin to use the back forward buttons to navigate once the site is in the history it will change the states dynamically like if the user was actually clicking through the nav, rather than needing to reload the page afterward. It only checks the hash if you are using the history to navigate.

I have a recommendation for a different approach. Lets say you have a link that goes to some page (but uses AJAX with no refreshing). When that link is clicked, you change the hash to whatever you like. Now, when the user clicks the back button, the hash changes back to what it was originally before the user clicked on the link...but what you could do is check if a click event was fired on a link or button (or whatever selector/event you want to check for). If it was fired, you know that request came from a click on the page itself. If there were no events fired that you're checking for, you know that the click came from the back or forward button.

Another thing you could do is append a suffix to the hash when it changes (from the back or forward button based on your checking of any events firing). So if you had a hash of #pageTitle you would turn it into #pageTitle_chrome to indicate that the hash was changed from the back button or forward button.

Then, when you're checking your hashes, you could just see if it contains _chrome to detect what kind of hash change it was.

You cannot do this with hashes, or even with the HTML5 History API. There are no events exclusively associated with the user clicking back or forward buttons. You probably need a different approach to the original problem, unless installing some kind of extensions or such on a client machine is feasible.