9

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?

Community
  • 1
  • 1
Ruben
  • 3,452
  • 31
  • 47
  • have a look here it seems related: http://stackoverflow.com/questions/2063742/differences-in-internet-explorer-and-firefox-when-dynamically-loading-content-th – Ryan May 30 '13 at 16:24
  • @ryan Thanks, I knew that question. It's related but the answers are about restoring state from various kinds of local storage, not about detecting "how good" bfcache is. – Ruben May 30 '13 at 16:36

1 Answers1

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";
Koen
  • 121
  • 1
  • 4
  • So basically you recommend I set some sort of flag in the DOM with which I can distinguish default state from non-default state? Because otherwise I'd end up storing all state changes twice, to find out whether there've been any edits. The thing is, now, there are no default/non-default states, any state can both be the thing that's loaded from the server and the thing that appears after user input. What would be a good way to set such a flag in this case? – Ruben Jan 21 '14 at 09:42
  • Set the flag when the user changes the state? AKA changes the input somewhere. – Koen Jan 21 '14 at 11:28
  • I'm sorry, this question is sort of old. I think I tried some things like that back then, but failed. Storing the state flag in a hidden input definitely didn't distinguish IE10's lousy bfcache from FF's and Chrome's (because IE10 stores inputs). But that's a sort of weak response, unfortunately I don't have the time or need to go back to my old problem. – Ruben Jan 22 '14 at 10:05