what will persist when returning via back button?

Question

I understand that a checkbox will remain checked when you return to a page via the back button. Classes added using jquery's addClass however do not. Can someone help me understand when something will persist or not when returning via the back button? Also, is there a way to save the value of a variable so that I can use the variable values to recreate the objects that did not persist?

Answer 1

Nothing persists - classes don't persist because DOM is regenerated, JS variables don't persist because code gets re-executed etc. At the same time, browser implementations seem to pretty much agree to keep user-entered form data for convenience even though this behaviour is not part of any official spec.

If you require some data to persist on the client-side - chances are you're doing something wrong architecturally. Why are you trying to override browser "back" button behaviour for the user to be taken back to an arbitrary state, rather than going to the previous URL and re-rendering the page? If your app is interaction-heavy and this "back" button behaviour is desired, you may want to back away from having the user navigate between independent pages in favour of making AJAX requests and relying on something like html5 history api allowing you to execute any arbitrary code to put the page into a desired state.

You don't go into enough details about what you actually expect to be store - maybe a localStorage or a cookie alternative would be more appropriate

Update:

I've put together a fiddle to test how well form data will persist when traversing history, and hidden fields were available to be processed by JS - still not a good idea though imo

Answer 2

Modern browsers try to persist more and more. Firefox experimented several years ago with preserving everything including class name changes, as long as the server indicates that the page is cachable in the HTTP header and the webpage has not registered any onunload event handlers. Firefox fires onpageshow and onpagehide when the user presses back.

https://developer.mozilla.org/en-US/docs/Using_Firefox_1.5_caching https://www.webkit.org/blog/516/webkit-page-cache-ii-the-unload-event/

Answer 3

It pretty much depends on the fact do you handle or not hash of the url, ie if you do, you can persist everything.

EDITED:

You have to be familiar with the concept of Single Page Application (SPA).

It is all possible thanks to ability to change location hash property and manage browser history.

In order to make this simple there are tons of libraries like Sammy.js

Each time you have user doing an action you push new state and thus you'll be able to handle pressing of back button.

In order to get idea of how it looks like, check following jsfiddle

In the code you see setting up routes:

Sammy(function() {
    this.get('#:folder', function() { ... });
    this.get('#:folder/:mailId', function() { ... });
})).run();

Which specify hash, ie www.mygreatwebsite.com/#inbox/#1 and how your app will handle it.

There is much more going on here, so my links are just starting point for you to explore.

EDITED: much simplier example of using sammy.js

Answer 4

Complementing the above answers, you can save the form state with viewstate.

• Understanding ASP.NET View State
• ASP.NET Web Forms - Maintaining the ViewState

ViewState allows ASP.NET to repopulate form fields on each postback to the server making sure that a form is not automatically cleared when the user hits the submit button.