Develop Reference

LocalStorage variable auto disappear

This is might be a dump question but i could not figure it out why.
So, i have to permanently store some configuration number into the browser, so if the app reload, it can get those config number right away. I think we can do it by using localStorage.
I implemented and got it working, using :
localStorage.setItem('token', 'fsdfdsfsdfdsfds');
localStorage.setItem('config1', 'config1');
localStorage.setItem('config2', 'config2');
localStorage.setItem('config3', 'config3);
However, after 2 hours all of the config1, config2, config3 are gone. Only the token one still exists in localStorage. I though that item in localStore should stay as long as we want. We have full control over it.
Any explain here ? Thanks

I suggest you use Chrome.storage.api, the data will persists when you close the browser. Works the same, key/pairs are stored and retrieved. I stopped using localStorage when I can do the same in Chrome.storage api.

I'm not sure how Chrome handles localStorage in incognito mode so I can't give you a detailed answer but one thing I know is that you can't rely on localStorage in incognito.
Check MDN -> Web Storage API -> Private Browsing / Incognito modes
Most modern browsers support a privacy option called 'Incognito', 'Private Browsing' or something similar that doesn't store data like history and cookies. This is fundamentally incompatible with Web Storage for obvious reasons. As such, browser vendors are experimenting with different scenarios for how to deal with this incompatibility.
Most browsers have opted for a strategy where storage APIs are still available and seemingly fully functional, with the one big difference that all stored data is wiped after the browser is closed. For these browsers there are still different interpretations of what should be done with existing stored data (from a regular browsing session). Should it be available to read when in Private mode? Then there are some browsers, most notably Safari, that have opted for a solution where storage is available, but is empty and has a quota of 0 bytes assigned, effectively making it impossible to write data to it.
Developers should be aware of these different implementations and take them into account when developing websites depending on Web Storage APIs. For more information please have a look at this WHATWG blog post that specifically deals with this topic.

Check if object fits into browser cache

I have a single page application, which loads a JSON data file from a server and displays it on the client. The data file only changes once per day, so after fetching it, I want to keep it cached on the client. So far, I have been using jStorage and am happy with the overall result. One thing is problematic though: according to the jStorage Browser support page, the cache size varies from browser to browser.
So my question: can I somehow find out if jStorage will be able to store all my data? The jStorage website itself does not give any clues to that.
Alternatively, since I'm only storing one big object, I could use a plug-in like sizeOf to check the object size before saving it, but I don't know if that is a reliable approach.

I am not sure how jStorage implements, you say 5mb so I guess it's using localstorage. Have you tried indexedDB which is browser native and theoretically limit to your hard drive capacity.
https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API

window.localStorage vs chrome.storage.local

I'm developing a Chrome extension and I need to store some data and then get it in some point. I did investigation on available storages and came across to the following ones: window.localStorage and chrome.storage.local.
So my question is, which one is the right choice to use in Chrome extensions:
window.localStorage or chrome.storage.local?
P.S. I'm using browser action to load a local HTML in IFRAME. So I'm not using popup.js.

localStorage
Pros:
Synchronous, and thus easier to work with: var value = localStorage[key]
Has support in Dev Tools: Resources > Local Storage to view and modify.
Cons:
Only stores strings, therefore you need to serialize data yourself, i.e. with JSON.stringify
Is not accessible from content scripts (or rather, context scripts share it with the page and not the extension), so you need to rely on Messaging to pass values to them.
Synchronous AND shared between concurrently-executing extension pages, leading to possible synchronization issues.
chrome.storage.local
Pros:
Automagically serializes JSON-compatible data, can store non-strings with no additional boilerplate.
Fully available within Content Scripts.
Supports events that notify about changes: chrome.storage.onChanged
With "unlimitedStorage" permission, can hold arbitrarily large amounts of data.
Has a nice built-in mechanism for default values:
chrome.storage.local.get({key: defaultValue}, function(value){/*...*/});
Fully supported in Firefox WebExtensions and Edge Extensions.
Cons:
Asynchronous, therefore a bit harder to work with:
chrome.storage.local.get("key", function(value){/* Continue here */});
Not visualized in Dev Tools; one needs to call chrome.storage.local.get(null) to get all values or use something like Storage Area Explorer.
chrome.storage.sync
Same as above, but:
Pros:
Automatically synced between signed-in Chrome instances, if extensions sync is enabled.
Cons:
Inflexible quotas on data size and update frequency.
As of 2016-11-06, not yet supported in either Firefox WebExtensions or Edge Extensions, so non-portable.
Note: storage.sync is now FF WebExtension compatible, though there is no way to make Chrome and FF natively sync between each other.

It depends entirely on what your Chrome Extension will be doing. window.localStorage is HTML5 storage. Unless you're running it in the background page, it can only allow you to get and set data into storage for a specific domain. This is also true for code injected into the DOM, since it would use the localStorage on the web page.
In other words, you won't be able to share data across different web pages unless you use localStorage in the background page, which operates independently of web pages, since it has a chrome:// URI as its domain.
chrome.storage.local, on the other hand, is designed for Chrome Extensions and Chrome Apps to store data in a more central location. Since this isn't accessible to normal web pages, each Extension gets its own storage. One possibility is for your background page to handle dealing with the setting and getting of the data, while your content scripts deal with modifying and interacting with the web page.
However, these API's work in content scripts as well, and both of the extensions I've written use chrome.storage.local called from the content scripts.
As an example, I built a Stack App that preserves inbox items in Stack Exchange until you've actually read them, called StackInbox. Since Stack Exchange sites span across hundreds of domains, I chose chrome.storage.local because I could save the user's accountId and reuse it across all the sites, ensuring that the inbox data is synchronized, while also using this directly in the content script.
As a simple test, put some data in localStorage on one domain, in a content script, and try to pull it from another, and you'll see that the data won't be there. With chrome.storage.local, this isn't a problem.
Lastly, Chrome Extensions and Chrome Apps are whitelisted, since the user chose to install it, so they typically can do more things than a normal website. For instance, by specifying the "unlimitedStorage" permission in your manifest, you can store data well beyond the 5MB limit placed upon HTML5 localStorage.
For more information, see Google's documentation on Chrome Storage.

localstorage or sessionstorage can't persist data on cross browser

I am working on a small application but I am stuck on a problem. I want stored form element values on a HTML page when filled in on one browser(Ex. Firefox) and auto fill data when same page is loaded in another browser(Ex. Chrome). If anybody has any ideas please help me.

Unless clients can login and you're willing to share this data via your server, you can not change behavior of a different browser from your current, so in your example Firefox can not change a cookie, localstorage or whatever of Chrome. Browsers tend to only share information like cookies when they are first ran; such as with you the import wizard from Firefox.
I can think of two alternatives to achieve this:
An authentication system where the data is stored server-side.
Through custom browser extensions. You could create a custom browser extension that directly writes the data of the other browsers. This does require the user to install that extension though.

This link explain how to achieve that http://www.nczonline.net/blog/2010/09/07/learning-from-xauth-cross-domain-localstorage/
It's not simple, but it's the way that I know it can be done at the moment without the use of cookies.

Web client cache

We are in process of building conceptual model of web-based audio editor. And the first trouble we met is client-side caching system. In my opinion as server-side programmer having huge cache on client side is perfect idea, because in many cases it takes of server load by excepting multiple loading of the same data. Furthermore such cache could be good candidate for buffer for providing per-track operations, like filtering.
Our flex programmer says that this is a great trouble and it is impossible in almost any cases. But I am in great doubt, cause I know that actual Google Chrome browser version can simple keep up to 2 Gb in localStorage. Moreover I've found this example of online track-editor and looks like its caching mechanism working pretty good.
Is it possible to cache some data (smth about 100-200mb) on the client side using flash and js?

You can use SharedObject to store the data.
I am pretty sure that default size limit is too low for your needs, so your app will need to ask user to accept your new limit:
http://www.macromedia.com/support/documentation/en/flashplayer/help/help06.html
SharedObject is more reliable than the browser cache, and you control it from your app.

If you are using html5 then you can store large data on client side using html5 inbuilt database.
also refer this link

What we did when writing a video editor. Well, actually, in Flash you can save files to the user's machine, with the restriction that it must be transparent to the user (i.e. the user initiates the action, goes through the OS dialog and saves the file as they would normally save anything they download), similarly, you can load in a file from a user's computer, with the restriction that the user must initiate the action (as in by clicking with a pointing device or pressing a key).
This has certain advantages over different local storage strategies, which are mostly opaque to users (people don't usually know how to erase cookies, SharedObjects or web storage that comes with more modern browsers, but they are pretty much capable of saving and deleting the files on their system). Furthermore, all other opaque local storages may have restrictions that less savvy users might not know how to overcome / may not be possible to overcome in general - these would be size, location and ownership.
This will still be a bit of hindrance for your audience, because every time they need to save a file, they have to go through the OS's dialog, instead of doing Ctrl+S / Cmd+S / C-x C-s... But given all other options, this, IMO, leaves the user with the most choices / delivers best experience.
Another suggestion - you could, in principle, come up with a browser-based "enhanced" version of your application, which users would install as a browser plugin (if that's an editor they are using on a regular basis - why not?), in which case you wouldn't be limited to the clumsy options provided by web technologies. Chrome and Mozilla-based browsers encourage such development, however it's not standardized. Still, since these two browsers run on virtually any OS, that doesn't sound particularly as locking in your users into a certain platform...