- Enter/change something in a textarea
- Before submitting the form, leave the page (e.g. by clicking browser's back button)
- Go back to the edit page (e.g. by clicking the forward button)
Expected result: the content entered in the textarea should still be there
Actual result:
- with HTTPS: all changes are gone (bad!)
- with HTTP: the changes are still there (good!)
Why is this happening when using HTTPS? How can I prevent this? Is the browser or the website responsible?
You can consider the following solutions:
The
autocomplete
Attribute (HTML5)This seems unrelated since
autocomplete
tells the browser to complete fields with the values based on earlier user input which were "submitted" with the form. But in my tests I saw that; after filling out the form without submitting; when I hit the forward (history) button and hit back again; form fields were auto-filled if I setautocomplete="on"
and all were cleared when set to"off"
.So; (if targeting HTML5 users) you can use this attribute to "cache" your form data. (Works on all major browsers, except Opera).
Notice that you can set the auto-complete feature off for a specific field (password in this case) when the rest of the form controls are on.
MSDN Remarks:
Save the Un-submitted Form Data Locally:
You can store the input data locally, right before the page redirection or on focus-out event of every form control:
Cookies
The good-old cookies can come handy in this case but you should consider the down-sides:
Http-Only
andSecure
marked cookies will not help us here, because these options are used to enforce SSL when the cookie is "sent" (secure) and cannot be accessed from Javascript (http-only).maxlength
attributes); that could be a problem. (and trimming the value is the worst thing in this case).Still, the bright side is they are supported by all browsers and if you don't plan to "cache" sensitive and too-long data via Cookies, then you can use the following solution. If this is not the case; you should better go with the next suggestion:
localStorage
.Here is a working demo on jsFiddle.
Note: The "cookies reader/writer" script from developer.mozilla.org should be included with the code above. You can also use Yahoo's YUI 2: Cookie Utility which has a useful setSub() method for setting sub-cookies inside a single cookie, for the browser limit that I previously mentioned.
localStorage
You can also use more modern techniques like
localStorage
(HTML5). It is more secure and faster. All major browsers support this feature including IE 8+. (Additionally, iOS and Android support!)So, just like in the cookies example;
SessionStorage
This works pretty much the same way. From W3C: The sessionStorage object is equal to the localStorage object, except that it stores the data for only one session.
Save Form Data to Server/DB via Silent AJAX Post(s):
Not a very efficient way but you might want to use this where others are not feasible. You can make the post on the
beforeunload
event and prompt a message to the user.Retrieve Previously Saved Data from Server on Page Load:
Just to remind you; if the user is filling out an "update" form, for example; you can always fetch the previously saved data from the server and automatically fill in the form (non-sensitive fields).
Conclusion
If you really need this and worth the trouble; you should consider a cross-browser solution that implements a fall-back mechanism; such as:
autocomplete
attribute. (You can embed the attribute in the HTML beforehand, or set it via Javascript/jQuery when you test for browser support.)Storage
object; go withlocalStorage
;cookies
.Note: For HTML5 feature detection, take a look at this page or this page or you can use Modernizr.
HTTPS Problem:
The reason, all form changes are gone when using HTTPS is that; it is a secure protocol. Forms are mostly used for user input and can (probably) contain sensitive data. So this behavior seems natural and expected. The solution(s) I offer above will work the same as they do on HTTP. So that should cover all your concerns.
Further reading: