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.
Related
I have a website which saves a stringified JavaScript object into the sessionStorage. It works well on desktop browsers - data survives over page reloads as per described on MDN.
On Android phones, it is not uncommon that a tab is reloaded when user switches back from another tab or when the browser is brought back from background to foreground, and I expect the sessionStorage will persist. This doesn't however seem to be the case. The sessionStorage is gone missing, as if a new session is created.
I have thought of using localStorage instead, which will not expire even if the session is closed. It doesn't really sort out all my problems though - as I expect a user can open it multiple times on multiple tabs, and do different things on each of them.
So my questions are:
Is the sessionStorage behavior described above as expected? If not, what can I do to rectify it?
If the behavior is as expected, and I have to rely on localStorage, how can I identify the object stored for each individual tab?
Thanks in advance for your help!
As others commented, SessionStorage is temporary by design. Mobile browser lifecycle is highly geared towards reducing resource usage and tabs are teardown more aggressively.
To workaround this issue, you can push a random tab ID to the URL and then prefix all LocalStorage keys with this ID. When tab is refreshed you simply read the tab ID from the URL and use it for accessing data in LocalStorage.
LocalStorage has a very simple API, so you could write a wrapper hiding the key prefixing away from your other code.
Yes, that is how sessionStorage works. The behavior is expected.
sessionStorage is unique per tab. If the user closes the tab the sessionStorage gets deleted.That is, the session storage is saved only as long as user stays on the tab.
Whatever you store in localStorage persists until explicitly deleted. Changes made are saved and available for all current and future visits to the site.
So, yes, it'd be better to use localStorage and clear it out at the end of the session.
I'm making a bookmarklet, and the bookmarklet goes to about:blank, then stores data under localStorage (technically, it downloads a script that stores data under localStorage)
The idea is that it downloads a script, and stores it under localStorage. That way, it doesn't have to download it again. However, there is no way of ensuring that one of the scripts won't try to edit the contents of another script (in localStorage).
So, I was wondering if it was possible to get a fresh context for localStorage, e.g. via going to about:blank/xyz. However, I do not want this to go to a website, even if the website is specially designed for this. I want this to be entirely local (the entire purpose behind this is to save bandwidth).
Or, being able to somehow sandbox localStorage would work too (in fact, that would be much preferred)
Any thoughts?
TL;DR I want to be able to have a fresh context for localStorage, without accessing a website (e.g. via about:blank, hence the title: Multiple about:blank's)
Run by the Ministry of Foreign Affairs (mid.ru), the web-site https://zp.midpass.ru/ lets one fill in various information in order to get a passport, and then print out all of these details right from the browser, along with a QR code to bring to the consulate, which supposedly has every single piece of information from the form encoded within it.
They claim that none of the operations, other than the passport photo upload, are performed through their server, and all data is saved locally. (E.g. anyone can try it out, without having to register etc.)
However, they don't seem to require any specific browser versions or anything, seemingly working everywhere.
How does it all work? Where do they save all of this data? Is there a way to export it, and import it into another browser / computer, other than printing it outright?
They use Local Storage. Using Chrome Developer Console I can go to the Resources tab and see that it stores that data using Local Storage after I click on "Save unfiled profile" - Google Translate.
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.
My organization is starting to use this feature and for testing it would be ideal if we could find and delete these values as well as see what's written to disk, but I can't figure out where IE8 is storing them. I found the .sqlite files in
AppData\Local\Apple Computer\Safari for Safari
and
AppData\Roaming\Mozilla\Firefox\Profiles\ryb7f27l.default\webappsstore.sqlite for FF3.5
Any help on IE8 would be appreciated!
The location of local storage on the file system is most likely an implementation detail that is not guaranteed to always be the same from version to version (it could even change with a service pack or update to IE).
To clear local storage using the approved methods, see Clearing the Storage Areas on the Introduction to DOM Storage MSDN page:
Clearing the Storage Areas
Session state is released as soon as
the last window to reference that data
is closed. However, users can clear
storage areas at any time by selecting
Delete Browsing History from the Tools
menu in Internet Explorer, selecting
the Cookies check box, and clicking
OK. This clears session and local
storage areas for all domains that are
not in the Favorites folder and resets
the storage quotas in the registry.
Clear the Preserve Favorite Site Data
check box to delete all storage areas,
regardless of source.
To delete key/value pairs from a
storage list, iterate over the
collection with removeItem or use
clear to remove all items at once.
Keep in mind that changes to a local
storage area are saved to disk
asynchronously.
An alternative to using the approved methods is to use a tool like Process Monitor to watch disk and Registry accesses while you write something to window.localStorage. Unfortunately, if you see it writing to a file like %userprofile%\Cookies\index.dat it would probably be unwise to delete that file (since it contains information about all the other cookies IE knows about).
EDIT: Using my own suggestion I found that local storage seems to be at %userprofile%\Local Settings\Application Data\Microsoft\Internet Explorer\DOMStore (in Windows XP, Vista and Windows 7 will be slightly different). They are just XML files but I'm not sure how safe they are to delete because of the index.dat (which may retain information about the existence of the XML files or their contents).
There are also some registry settings that might relate to this under:
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\LowRegistry\DOMStorage
Deleting the localhost[1].xml from the appropriate directory under %userprofile%\Local Settings\Application Data\Microsoft\Internet Explorer\DOMStore solved the problem.