Feature-detect bfcache?

Question

I was surprised by this problem in IE10 when using the back button to go to a page whose DOM had been modified:

I would have been happy with either behaviour 1 or 2, but not 3:

1. properly restore the entire state (like FF and Chrome do)
2. reload the page (as it shouldn't be cached) and the current state could be recreated because changes were pushed to the server via Ajax (IE8 does this)
3. but IE10 went back to the initial, unmodified page (it preserves form input, if there was any on the initial page, but not the entire state)

Because I was in a hurry, I just went with forcing a reload if someone accesses the page after making DOM modifications (that piece of info is stored in the hash), which is a pretty dumb solution (FF and Chrome don't need to reload, but now do).

One suggestion was to use localStorage to remember state and I'm guessing this kind of functionality is also rolled into history.js.

To keep a spare copy lying around for comparison / in case state isn't restored seems overkill, especially because in our case this is a problem that would afflict maybe 0.01% of users. For my purposes, it would be sufficient to force a reload if the state has not been saved in its entirety in the bfcache.

Can I "simply" detect whether there is a all-state-encompassing bfcache? If so, I could force a reload in its absence when someone goes back to a page whose DOM was modified?

Answer 1

You can refresh the page if the browser user-agent/browser is known for not saving the modified state.

You can alternatively append "#modified" to the URL after the state is modified, so if the URL contains "#modified" but the state is default you know you should refresh the page, because the state din't get cached correctly.

if(document.location.hash == "#HelloWorld")
{
    // Check if state is default
    // If state is default, the page should be refreshed
}
document.location.hash = "#HelloWorld";