We Keep Coding

Text fields don't get updated using the browser back button

I have been looking for information about this but I don't get with the solution.
I have some text fields on a page which I get updated on blur making use of jQuery events.
There's no form to submit, the update took place in the background using jQuery $.post.
If a user updates those inputs, then clicks on a link to go to another section of the page and then comes back using the browser's back button, those inputs won't show the last values set by the user but the previous ones in case there were, or empty text inputs if there weren't.
Users are reporting this as a bug (even is more a browser behavior), and I wonder if there is any solution for this.
I have been taking a look at things like this or this, but they don't solve the problem I have. I have no forms, I have no submit and I don't want to reset the form.
I've noticed this problem doesn't take place in IE 9 and either in Firefox but it does on Chrome.
The user can navigate to different pages (more than 30) with more than 12 text fields in each and therefor I have discarded the idea of storing them on sessions.
Is there any way to solve it?
Thanks.

I do not know if my solution can solve you're problem , but:
what if you bind data to you're input? e.g you can set dinamically data on input
$('input').data( 'val' , $(this).val());
and then re-bind it through
$('input').val( $(this).data() ) ;
Do not follow exactly these lines of code , I'm trying to give you an idea of what I'm wondering. I hope that it can help you.
http://api.jquery.com/data/ doc for .data()

Is it possible for the browser to cache Javascript/DOM changes?

I am developing a form using Javascript for styling that will be used to submit many different things. However, the majority of the time the different things will only be slightly different so it would really benefit users if when you press the Back button on the browser, the form is exactly as you left it before you submitted the form.
Note: This already works when using a normal HTML/Javascript-less form, the question I am asking is how I can retain this functionality when using Javascript to hide/replace input fields etc.
I've tried History.js and HTML5's replaceState() but nothing seems to work. Also if it helps, this will be a private website that requires the latest browser installed so don't feel hesitant to recommend solutions only available in the latest browser releases.
Many thanks!
Update #1: Here's an image better explaining what I need.
Update #2: Okay I managed to crack it perfectly, cross-browser included. I'll post a solution tomorrow after I've had some sleep.

Okay so I went back to the drawing board and tried to figure something out using the tools I already know exist. The case with each browser (usually, haven't tested any non-major browsers) is that when you press the Back button after submitting a form, text input fields are usually populated. I wanted to see if this worked the same with hidden input fields, turns out it does!
So next I set up some Javascript events to listen out for the page load.
if($.browser.mozilla)
{
$(window).on('pageshow', pageManager.init);
}
else
{
$(pageManager.init);
}
This works for Chrome, Firefox and IE9. I haven't tested any other browsers but these are the only browsers that will be used for my private site so it's good enough for me. I'm sure you can set up your own preferred solution for your needs but this is what worked best for me.
Anyway the above code means every time the page loads, pageManager.init() will run. Here's an excerpt of the code I use to check if the Back button was pressed and it's not simply just a page refresh or a first-time visit:
if($('input[name="form_submitted"]').val() != '')
{
// back button was pressed
}
As you can see, it's as simple as checking if your hidden form field contains a value. To actually guarantee a value will be set, make sure to set on submission of your form:
$('#my-form').submit(function()
{
$('input[name="form_submitted"]').val('true');
}
It really is as simple as that. This is one of the best methods I can think of for determining if the Back button of a browser was pressed. Now, to cache all the form values for the visible fields it can be as simple as using JSON.stringify() on the fields and sticking it all in one hidden field which you decode later.

AFAIK, this is generally handled manually. That is, you use hashtags or pushState (with appropriate state object) and either on hash change or on popstate you grab the hash/state, and (re)build your DOM as needed.
(note, I combined two very different scenarios into one there, sorry. if you were only using hash changes, you wouldn't likely be using pushState, as pushState doesn't trigger onhashchange according to MDN.)

JS page formatting is not retained when navigating away from a page and back

I have a bit of an issue with page formatting when I navigate away, and then hit browser back to a page.
Here is an example:
I have security questions on a form in a drop down list like so:
http://i.stack.imgur.com/ib32z.jpg
When the user selects [Type in your own question] from the drop down list, I have some jquery that animates a CSS change that pushes the form down, and makes visible a hidden field for 'custom security question'. When selected, the form looks like this:
http://i.stack.imgur.com/uVPKo.jpg
Now my dilemma is when I navigate away from this page, and then navigate back using the browsers back button, my formatting gets screwed up and looks like this:
http://i.stack.imgur.com/5Xhpi.jpg
The javascript that I have written does not trigger again on the back button so the browser doesn't know to move the form back down to accomodate the change in spacing. Is there anyway I can force the document.ready to reload or clear some kind of cache?
Thanks!
EDIT: Sorry guys, I need to reupload the images to a host and repost. Sorry for the delay.

There are basically four mechanisms for persisting state on the web:
Browser-based - the browser, if you're lucky, will save answers to form fields and re-display them when it sees an INPUT with the same name; also, some browsers will preserve some state between forward<=>back navigation
Cookie-based - pretty self-explanatory; you save a cookie with the state info, and check it later to recover the state
URL-based - navigate to a different hash of your URL, with the info you want in it (eg. "?roll_down=true")
HTML5/Local Storage - Look it up if you're interested :-)
We can basically throw 1 and 4 out, because they both rely too much on browser behavior/support, and we can't reliably rely on all browsers to handle them the way we want. That leaves #2 or #3.
Cookies allow you to save more info (as much as a cookie holds, ie. about 4k). URLs allow less info, but they have the added benefit of bookmark-ability; if the user saves the URL as a bookmark (or as a link they send a friend, or whatever), the state still gets preserved.
So, take your pick of the above, decide on how to persist your "my form is rolled down" state ... and then comes the part that (I think) you're really interested in: how do you check this state and fix things when the user clicks "back"?
That part I humbly defer to another SO post, which has already answered it:
Is there a way to catch the back button event in javascript?

Why does Firefox + My code Destroys FireFox refresh

I am soo angry right now. I lost hours and i dont know why this happens. Its a semi rant but i'll try to keep it short
My code would not work, even after refreshing it was broken
I fixed my code or so i thought because it stops working without me changing anything (you would think i am imagining this...)
I somehow decide to make a new window or tab i run my code and verifies it works.
I write more code and see everything is broken again
I write test in a new window and see my code does work
I see my code doesnt work and firebug DOES NOT HELP
I notice when i create a new tab everything works
I realize refreshing does not work and i MUST make a new tab for my code to work.
Then i knew instantly what the problem was. I modify a display:none textbox but i set the values incorrectly. I cant see it because it is hidden. Now some of you might say its my fault because when doing a refresh all of the data may be cache. But here is the kicker. I was using POST data. I posted in between of the refresh each and everytime.
Whats the point of using POST when the same data is cached and use anyways? If theres no chance for a search engine to follow a block user get link then why should i bother making anything post when security or repeat actions are not an issue? POST didnt seem to do anything.

Sounds like you're being hit by form-field-value-remembering.
When you use back and forward (but when the bfcache isn't used in browsers that have it), or in some browsers when you hit reload, the browser attempts to keep the values of each form field that were present when the page was last unloaded. This is a feature intended to allow the user to navigate and refresh forms without losing all the data they're laboriously typed into them.
So you can't rely on the value of a form field being the same at page load time as it appears it should be from the HTML source. If you have DOM state that depends on the value of a form field (such as for example a form where some of the fields are hidden or disabled depending on the value of another field), you must update that state at page load time to reflect the field values that the browser has silently dropped into place (no onchange events occur). And don't use hidden inputs to store scripting variables at all.
The exact behaviour varies across browsers. For example some browsers keep the values of hidden fields and some don't. Mozilla and WebKit put the new values in instantly as the fields are parsed into the DOM, whilst IE only does it on window.onload... and Opera, aggravatingly, does it just after window.onload, so you can only catch it by setting a 0-timeout to update state after onload. It's a nasty mess.

Dealing with unsaved form data when user closes the browser

I'm having hard time trying to figure out how to auto-save user data in a form when the browser is being closed or user changes the page. The onBeforeUnload event is OK when you want to open a dialog box, but by then it's too late to save the changes (except if you just block the browser in the onBeforeUnload handler long enough for it to pass the request to the server...but I'd rather not do that).
I am sure some of you have had to deal with the unsaved form problem. What do you do? Do you:
let users just lose their changes,
ask them using a modal window if they are sure they did the right thing,
save individual fields on the fly as they change,
or do you have some ultimate method to automagically save the data when it's about to be lost irretrievably?

•ask them using a modal window if they are sure they do the right thing,
Closing a window is an act of cancellation. As the user never actively submitted the form, theres no guarantee that they want the data saved (it may not be correct), and you saving the data could cause problems for the user.

I like your third option:
save individual fields on the fly as they change.
I'm having to deal with a similar situation, and that's what we are doing. The two main things that sell that to me:
Improved user experience - the user
will be impressed by a form that
does not lose changes. They are
'committed' once they are validated.
E.g., he types in a valid email
address, and it is saved instantly,
furthermore he is provided some sort
of feedback for each field that is
successfully been saved (a green
tick for example, appears next to
the field).
No more 'oh crap my browser crashed
and I lost all my info' situations.
Disadvantages: The extra man-hours involved in developing such a solution, and the possibly that it ends up not degrading as nicely as a simpler solution. That said, it is still worth it IMO.

In any browser I have used it in, onBeforeUnload provides you with a modal window which asks the user to confirm whether they want to leave the page or not. You can added your own text warning them that there is unsaved data, to help them decide. You don't want to explicitly save without the user's request, because a) the user did not attempt to save, and b) if you need to throw any validation errors it will be too late as the page is already in the process of navigating away.