How to tell the difference between 'real' and 'virtual' onpopstate events

Question

I'm building a tool that uses AJAX and pushState / replaceState on top of a non-javascript fallback ( http://biologos.org/resources/find ). Basically, it's a search tool that returns a list of real HTML links (clicking a link takes you out of the tool).

I am using onpopstate so the user can navigate through their query history created by pushState . This event also fires when navigating back from a real link (one NOT created with pushState but by actual browser navigation). I don't want it to fire here.

So here's my question: how can I tell the difference between a onpopstate event coming from a pushState history item, vs one that comes from real navigation?

I want to do something like this:

window.onpopstate = function(event){
  if(event.realClick) return;

  // otherwise do something

}

I've tried onpopstate handler - ajax back button but with no luck :(

Thanks in advance!

EDIT: A problem here is the way different browsers handle the onpopstate event. Here's what seems to be happening:

Chrome

• Fires onpopstate on both real and virtual events
• Actually re-runs javascript (so setting loaded=false will actually test false)
• The solution in the above link actually works!

Firefox

• Only fires onpopstate on virtual events
• Actually re-runs javascript (so setting loaded=false will actually test false)
• For the linked solution to actually work, loaded needs to be set true on page load, which breaks Chrome!

Safari

• Fires onpopstate on both real and virtual events
• Seems to NOT re-run javascript before the event (so loaded will be true if previously set to be true!)

Hopefully I'm just missing something...

Answer 1

You may be able to use history.js . It should give you an API that behaves consistently across all major platforms (though it's possible that it does not address this specific issue; you'll have to try it to find out).

However, in my opinion, the best way to handle this (and other related issues too) is to design your application in such a way that these issues don't matter. Keep track of your application's state yourself, instead of relying exclusively on the state object in the history stack.

Keep track of what page your application is currently showing . Track it in a variable -- separate from window.location . When a navigation event (including popstate) arrives, compare your known current page to the requested next page . Start by figuring out whether or not a page change is actually required. If so, then render the requested page, and call pushState if necessary (only call pushState for "normal" navigation -- never in response to a popstate event).

The same code that handles popstate, should also handle your normal navigation. As far as your application is concerned, there should be no difference (except that normal nav includes a call to pushState, while popstate-driven nav does not).

Here's the basic idea in code (see the live example at jsBin )

// keep track of the current page.
var currentPage = null;

// This function will be called every time a navigation
// is requested, whether the navigation request is due to
// back/forward button, or whether it comes from calling
// the `goTo` function in response to a user's click... 
// either way, this function will be called. 
// 
// The argument `pathToShow` will indicate the pathname of
// the page that is being requested. The var `currentPage` 
// will contain the pathname of the currently visible page.
// `currentPage` will be `null` if we're coming in from 
// some other site.
// 
// Don't call `_renderPage(path)` directly.  Instead call
// `goTo(path)` (eg. in response to the user clicking a link
// in your app).
//
function _renderPage(pathToShow) {
  if (currentPage === pathToShow) {
    // if we're already on the proper page, then do nothing.
    // return false to indicate that no actual navigation 
    // happened.
    //
    return false;
  }

  // ...
  // your data fetching and page-rendering 
  // logic goes here
  // ...

  console.log("renderPage");
  console.log("  prev page  : " + currentPage);
  console.log("  next page  : " + pathToShow);

  // be sure to update `currentPage`
  currentPage = pathToShow;

  // return true to indicate that a real navigation
  // happened, and should be stored in history stack
  // (eg. via pushState - see `function goTo()` below).
  return true;
}

// listen for popstate events, so we can handle 
// fwd/back buttons...
//
window.addEventListener('popstate', function(evt) {
  // ask the app to show the requested page
  // this will be a no-op if we're already on the
  // proper page.
  _renderPage(window.location.pathname);
});

// call this function directly whenever you want to perform
// a navigation (eg. when the user clicks a link or button).
// 
function goTo(path) {

  // turn `path` into an absolute path, so it will compare
  // with `window.location.pathname`. (you probably want
  // something a bit more robust here... but this is just 
  // an example).
  //
  var basePath, absPath;
  if (path[0] === '/') {
    absPath = path;
  } else {
    basePath = window.location.pathname.split('/');
    basePath.pop();
    basePath = basePath.join('/');    
    absPath = basePath + '/' + path;
  }

  // now show that page, and push it onto the history stack.
  var changedPages = _renderPage(absPath);
  if (changedPages) {
    // if renderPage says that a navigation happened, then
    // store it on the history stack, so the back/fwd buttons
    // will work.
    history.pushState({}, document.title, absPath);
  }
}

// whenever the javascript is executed (or "re-executed"), 
// just render whatever page is indicated in the browser's 
// address-bar at this time.
//
_renderPage(window.location.pathname);

If you check out the example on jsBin , you'll see that the _renderPage function is called every time the app requests a transition to a new page -- whether it's due to popstate (eg. back/fwd button), or it's due to calling goTo(page) (eg. a user action of some sort). It's even called when the page first loads.

Your logic, in the _renderPage function can use the value of currentPage to determine "where the request is coming from". If we're coming from an outside site then currentPage will be null , otherwise, it will contain the pathname of the currently visible page.