#history api

UPDATE [08/28/13]: 

NEW feature: Seamless Cross-page Playback. You can now keep Streampad v2 playing while navigating through your own blog’s pages! No more music resetting for users without infinite scroll! ;) This is enabled by default, but it is still an experimental feature so you may experience some problems. Needless to say, I’ve done almost a week’s worth of testing up to this point so it should be alright, but if you’re having trouble you can turn it off.

Also, I’ve condensed the scripts into one so the copy-and-paste won’t be as large.

Get the updated Streampad v2 here!

(Note: you'll need to delete everything you've copied from previous installations and re-paste the entire code since this introduces another option to your Customization. Or you can add the <meta> tag in manually if you know how.)

---

Achieved using iframes and HTML5 history.pushState. Everything written in vanilla javascript! Longer explanation will be written in the future when I find spare time.

I was stuck for a good day and a half debugging some navigation issues on my site caused by some incorrect usage of the HTML5 history API.  I think they're pretty easy mistakes for a beginner to make.

First a quick description of my app.  It's implemented as one HTML page, but internally, I keep track of a stack of "views", with one view visible at a time.  The user can navigate forward and backwards between the views.  The views are actually individual <div> elements, but only one, the "top", is visible at a time.  I have my own pushView() and popView() functions.  It would be nice if the "back" button to mimic the view navigation, ie it would call popView().

It seems straightforward...

The solution seems pretty simple.  Every time I navigate forward, I call:

history.pushState(data, title, url);

Then I need an onpopstate handler to handle the back button click.  If I'm navigating from one of the my views, I would call popView().

Now I noticed in Chrome, I would sometimes get onpopstate events at weird times, like first thing after I load a page.  It's easy to avoid these as long as a provide history data (the first param in pushState).  Then I can check the onpopstate events to make sure I have data before I act on it.

Confusing the states

The first thing that caught me is that onpopstate will return with the state data of the destination state, which is most likely NOT that last state you pushed.  Here's an example.  First you land on a page your history state would look something like this:

1. Landed on page state.  state data = null.

Then you call pushState("mydata").  Your history state would then be:

1. Landed on page state.  state data = null.

2. pushState("mydata").  state data = "mydata".

You then click the browser "Back" button.  To me at least, intuitively, I expected an onpopstate event with "mydata".  Instead, I get null.  What happens is that state 2  is popped, and state 1 is the page that should be visible now.  The onpopstate event carries the state data for state 1, which is null.

I had a bug where I couldn't navigate back to state 1 because I was checking for state data.  The fix for me was to use history.replaceState("main") to set the state data for state 1.

Unexpected states from links

My second source of confusion was that I used a combination of <button> and <a href="#"> elements to allow users to navigate my web app.  In both cases, Javascript handlers actually did the navigation.

The problem was the <a href="#"> elements.  Even though they did not navigate away from the page, clicking on them would have the side effect of adding an unexpected entry to the history state queue.  Make sure you add event.preventDefault() to the click handler for <a href="#"> links to avoid this.

Navigating back multiple pages is tricky

At some points in my app, I wanted to navigate back a two steps.  So I tried calling history.back() twice within a click handler.  This didn't work.  I only got one onpopstate event, going back one page.