I have a html form which collects data in input elements and then generates a PDF (using jsPDF) for the user to download (using Downloadify js). The data collected contains personal information.
What I need to know is will the data entered into the input elements, which then gets processed by JavaScript, remain in browser memory when the user navigates elsewhere or closes the browser window?
Yes it will probably remain in memory for a period. This is beyond you control, and will differ between browsers and operating systems.
If your form is not actually submitted to the server, autocomplete should not store it, although you may want to add autocomplete="off" to be extra sure of this.
You could also use JavaScript to set the form values to blank once processing is done.
document.getElementById('name').value = '';
You could also set any JavaScript objects to null after use. This will not guarantee that the data would not be held in memory somewhere. You could encourage users to close all browser windows after use and logout of the operating system if this is a concern. Browsers such as Chrome can remain in memory even though all windows are closed as it can live in the system tray if that option is set so logging out will force it to close whilst being easy for users to do.
Yes. The form data is saved in browser memory even if the user navigates to other page or closes the tab. It will saved in temporary browser auto-fill cache. You can disable this by using the attribute autocomplete="off" for form elements.
You can find more about autocomplete attribute here:
http://www.w3schools.com/tags/att_input_autocomplete.asp
Set autocomplete off. Auto fill will not save if this Is set.
Set Cache Headers in the response to not cache. Browser will not cache the page and discard when closed.
Related
The Twitter input box is much more than your average INPUT or textarea. First off, it isn't an input or textarea at all. They are instead using a well crafted DIV with a "role" attribute. for the entire text; likely capturing keystokes as they occur.
If a user is logged in, they can compose a tweet. If during that very cautious 140 character sprint, they accidentally click somewhere on the page, the browser GETs another page.
But when the user hits "back", the DIV then repopulates (after a second), with the users partially drafted tweet.
In terms of browser capability, how is this "saved form field" being accomplished?
I'm guessing to achieve this, one could implement either:
local-storage
This would just involve writing to the local storage upon each keystroke. Upon loading the page, the JS populates the tweet composer with the session local storage. See a live example of utilizing local storage. This would be nice and slick, but a major limitation is that this is limited to HTML5 browsers.
AJAX callback
Similar to the first method, but instead of writing to local-storage, the draft tweet is written to a web service. Upon loading the page, a callback is made to retrieve the content; populating the tweet composer.
Cookie approach.
Similar to the local-storage, but would write to cookie cache. The benefit with this method might be more ubiquitous browser support.
I'd love for someone to explain the pro's/con's of each method along with some sample code. Bonus if it's under 140 characters for each code sample :) (j/k).
HTML5 introduced some really neat tools to manipulate the browser history, namely the history.pushState/replaceState methods and the onpopstate event, so we don't have to rely on location.hashes to display a meaningful url for our web applications.
(Or better, we won't have to rely on hashes when the adoption of IE<10 will be negligible.)
Using the browser's back and forward button doesn't reload the page if the targeted state was created using history.pushState, even if the URL looks completely different.
However, unlike changing the hash, if the user changes the url from the browser's address bar, the browser does reload the page. Somehow I doubt there's an effective solution for this, but the question is: is there a way to prevent the browser to reload the page, and force it to push an history state instead?
I don't believe so. AFAIK, manually entering an address in the address bar - unlike clicking a link, back/forward buttons, pushstate/popstate, and form submit - is defined as requesting a new page, unless you change a hash (like in the pre-html5 days).
No. It isn't possible to interrupt the loading of new pages via the address bar (except for unload events, but they can only give you "Are you sure you want to leave the current page?" interruptions).
The real URLs should be handled by your server which should build the page into the expected state for that URL before delivering it to the client.
can user disable the HTML5 sessionStorage just how he can disable cookies?
Also is sessionStorage will valid till page refresh? I mean what session actually mean, is it page refresh?
Yes. HTML5 sessionStorage (and localStorage) can be disabled, and the data can also be cleared.
It is easy to prevent browsers from accepting localStorage and sessionStorage.
In FireFox: Type “about:config” in your address bar and hit enter to
view your internal browser settings. Scroll down to
„dom.storage.enabled“, right click on it and hit „Toggle“ to disable
the DOM Storage.
In Internet Explorer: Select “Extras” -> “Internet Options” ->
“Advanced” Tab -> Go to “Security” -> uncheck “Enable DOM-Storage”
In Chrome: Open “Options” and select “Under the Hood” Tab. Click on
“Content settings…”, select “Cookies” and set “Block sites from
setting any data”.
Also note: There are some browser security plugins/extras/add-ons that will prevent localStorage. If localStorage / sessionStorage is vital to your page operation you should attempt a test read-write.
Regarding your other question: sessionStorage will survive a page refresh. localStorage will persist between browsing sessions and survive a browser restart.
can user disable the HTML5 sessionStorage just how he can disable cookies?
A User can either clear the cookies or Disallow any website from setting the cookie for themselves.Every browser has that option.
For Example-:Block Cookies
I mean what session actually mean, is it page refresh?
First of all,its not a page refresh
Most simple analogy:Session is a token which allows the user to visit any area of a web app.This token is valid untill the browser close.The moment you close the browser all the session data will get cleared.
So what if i want my data to persist a little longer,Say i want permanently(considering that user have not cleared cookies) store some value on my users browser.
LOCAL STORAGE:Local storage allows the data to persist beyond the browser close.So when the user comes back,we can use that data in our application.We can set the expiry for it.We can clear it when we want.
NOTE:IE7 + support for SessionStorage and LocalStorage
Conventional cookie storage:This is our good old way of storing some data on client.All browsers support it.But the problem is they provide too less space.
A cookie provides 4kb space and for every domain there is a limit of
around 15-20 cookies.
LocalStorage and SessionStorage comes to our rescue.They provide quite good space.
Different browsers have different capacity.
IE(10 mb)...Surprise surprise
Mozzilla(5 mb)
Chrome(2.5 mb)
So,basically i can use localStorage if i want the data to persist beyond browser close and SessionStorage if i want the data to persist with in the browser close.
There are some js availabe also..
jStorage DOCUMENTATION
persist.js DOCUMENTATION
sessionStorage is used for session-based data. It is erased when the tab is closed according to the standard. You should use localStorage to persist across tab/window closings. Of course browsers can always not support these features or disable them, so you should handle that edge case to ensure your site remains functional. The best way to do this is to revert back to using cookies or use a compatibility library like this one.
I am working on a Chrome extension that needs to save some information (tabs info mainly) that will exist throughout the lifetime of the extension (e.g , since the user starts using it until he closes the browser).
One option is to use localstorage, however localstorage can only save Strings and that makes it very uncomfortable for me (since I have a bunch of data to save - dates , URLs , integers etc). What I'm looking for is using my own javascript objects that will live throughout the time of the extension.
Now the problem is that defining these objects in a script in some javascript files will erase them each time the user clicks on the browser action . In other words I have a browser action called popup.html that includes a javascript file (in which I want to save my objects) and every time the user clicks on the browser action all the objects I defined in the JS file are lost, yet I want everything to be persisted .
What option do I have to keep data that persists through many clicks on the browser action and that is NOT localstorage?
You really should use localStorage (you may use JSON.stringify and JSON.parse).
If you really don't want to use localStorage nor a server side storage, use IndexedDb : https://developer.mozilla.org/en/IndexedDB/Using_IndexedDB
Try using the Filesystem API's persistent storage. That is more reliable than localStorage. localStorage will be cleared once the user clears the cache, cookies etc. Filesystem is more reliable.
This answer about using chrome.storage worked for me far better than the others.
https://stackoverflow.com/a/14009240/766115
It's like localStorage, but works between the popup / background and content scripts.
This question already has answers here:
Persist variables between page loads
(4 answers)
Closed 7 years ago.
Is it possible to keep my (global) variables when the page is reloaded? If yes, how?
Thanks for any help.
Best regards.
Try this cookie-less javascript function.
It basically store your data in the window.name property which does not clear the value when you reload the page or goes to another site.
You can persist data across page reloads via something like window.localStorage, window.sessionStorage (proprietary Mozilla extension) or database abstraction (window.openDatabase) provided by some of the WebKit -based browsers. See this article on MDC for a nice overview of Storage interfaces and this WebKit article on their database introduction.
In the same style you can store string values in the hash key.
Using the property:
window.location.hash = 'flight/105';
Then when refreshing the page you initialize back your variables.
The JavaScript environment will be reset when the browser leaves your page. However, you could register an onUnload handler to serialise your array to a cookie, then check for this every time the page is loaded and unserialise it if present.
Does your browser have a reset button, or do you mean the reload button?
When the page loads, everything is loaded fresh. There is nothing left from any previous page. The only place to store anything that survives loading a page is in a cookie.
Note that the amount of data that you can put in cookies is limited to a few kilobytes per site. The exact limit varies from browser to browser, but you can't expect to be able to put more than perhaps a kilobyte or two worth of data in cookies.
Are you talking about Cookies? If so you might want to review this open-source module
This will easily allow you to store cookies, that is data, even after a browser reload click. This makes doing it really easy and it is what I use.
var cookie = new HTTP.Cookies();
cookie.write('mydata', 'myvalue', '+1y');
//later on you can get that data EVEN AFTER a reload
var x = cookie.read('mydata');
You probably shouldn't try to make a cookies implementation from scratch though because it is very painful and you have to do a lot of testing across web browsers, such as to make sure Internet Explorer works.