Develop Reference

Client side (persistent) storage

I've seen there are ways to store data on the client, e.g. using localStorage, sessionStorage, or indexedDB.
AFAIK the main disadvantage of these technologies is that the browser may decide to clear out the stored data say if the device is low on memory (not sure if this is true also about localStorage).
I seem to fail to find information on some alternative storage which is more persistent: e.g. won't get deleted by a browser based on some decision.
Is there such a technology available? I am looking to use it next to ServiceWorkers for an offline first app.
I found something like this, is this something included with ServiceWorkers? (The article doesn't show much API). How is the support from browsers?
clarification: I am fine if the data can be deleted by user, I don't want it to be deleted by browser automatically based on some decision.

Since your app runs on clients' devices, and you don't have any real control on it, and your desire is impossible (' browser may decide to clear out the stored data' - not true. browsers might not be able to store data, or to get a reference to storages in some browsers and scenarios - e.g safari iframe and localstorage are not friends...)
Service worker do support indexedDB, so why not using it?

Chome Extension - QuotaExceededError localStorage

I'm developing a Chrome extension and using old localStorage to store settings and cache instead of new chrome.storage.local and chrome.storage.sync. I have unlimitedStorage permission and then my cache becomes huge. I'm receiving QuotaExceededError.
How to overcome the problem?

localStorage is not, and will not be, unlimited
The fact that the unlimitedStorage permission does not apply to localStorage is stated in the documentation. The referenced bug, issue 58985, was marked as "WontFix" in December of 2010. Thus, there is not, and will not be, a solution for you to store unlimited data in localStorage. You will need to select some other method of storing your data.
Unlimited storage options
storage.local
Your options include chrome.storage which is explicitly intended for extensions to store data. You can store data that is local to the machine, using storage.local (can be unlimited with the unlimitedStorage permission), or data that is synchronized across the user's Google account, with storage.sync (quota is not set to unlimited by unlimitedStorage).
Web SQL Database
There are other options for storing data. For instance, the Web SQL Database, which is specifically granted unlimited storage by the unlimitedStorage permission.
HTML5 local File API (MDN)
The amount of data you can store with the File API becomes unlimited with the unlimitedStorage permission. You can also separately request a specific quota size with a call to webkitStorageInfo.requestQuota(), without using the unlimitedStorage permission. When you do, the user will be asked to approve the storage request. If you do use the unlimitedStorage permission, you do not need to separately request a quota.
What to use
What is best to use will depend on exactly what you are using storage for. You have provided no information as to your actual use, so there is no way for us to gauge what might be a good fit in your case.
Application cache
As to your issue with the application cache growing to a large size with the unlimitedStorage permission: Yes, the documenation explicitly states that declaring the unlimitedStorage permission will result in the application cache becoming unlimited. If this is an issue, you will need to not declare the unlimitedStorage permission.

generate fingerprint of client using javascript

How can i generate unique fingerprint of each client?
I know must use navigator object but some properties like navigator.battery cannot use in this method.
// battery included and unique may change.
var uniqueHash = exampleHash(JSON.stringify(navigator));
How can i generate correct unique fingerprint for each user just using JavaScript and without cookie.
Cross platform and older browser also must be included.
I need list of cross browser supported by navigator.X
Note:
I don't want to generate random hash. i want to generate system base hash for each user and i dont wanna save on Cookie or Storage.

How can i generate unique fingerprint of each client?
Short answer is that you can't. It's impossible to do this for every client. You can get close using invasive profiling of the client, but you'll probably only get a unique identifier in around 90-95% of cases.
and i dont wanna save on Cookie or Storage.
Is there a reason you don't want to store data client side? If you told us what you were trying to achieve then maybe we could suggest a better way to solve the problem.

One route that may be worth looking into is using the Mozilla Persona API. It exposes a navigator.id property for consumption. Getting a unique id from a user is as simple as...
navigator.id.get(function(unique_id) {
alert("this is your unique id: " + unique_id);
})
This has the downside of requiring user authorization
Example: http://jsfiddle.net/aJsL9/1/

Simplest way to keep a session without using cookies is appending a unique hash (maybe a UUID or something similar) to the urls in the page as a get parameter:
/my/fancy/url
becomes
/my/fancy/url?HASHCODE
whenever the server receives a request, it capture the HASHCODE if present, otherwise it generates one, and then append it to all links on the served page.
Please bear in mind that the user can manipulate the HASHCODE and you should take that into account when engineering your application.
Anyway, notice that it's quite ugly in the fancy-url era. Also notice that user tracking is a delicate subject and you might incur into legal problems if you do not properly declare it in the TOS.
EDIT: you cannot track a person across multiple web sites without using cookies in any of their variants (flash, session storage, etc.) and a domain shared between sites. No way, you cannot set a variable or cookie from one domain and access it from another one in any decent browser, otherwise it would be a big security hole.
EDIT: Panopticlick cannot be used as a tracking method as you suggested, because it is based on statistical matching and it is also pretty bad at that (try browsing https://panopticlick.eff.org/ from outside the USA or with the just-released Chrome/Firefox update). It's a good proof concept, but nothing that you can use for this purpose. Also, you would need a whole lot of samples to get statistically relevant results.
EDIT: Browser fingerprint identifying power is weak: many browsers are autoupdating (like Chrome or Firefox) and official builts are very few (20? 40? Maybe a bit more if you count Linux distribution-compiled ones), so you will find a consistent portion of users with the same user agent. Add that there is a pletora of consumer PCs with similar configurations.

Cookie size restriction in IE

I need to save a form state (values for input elements).
But the form is not a standard html form so the browser would not save the form state.
I need to store the form state as cookie I cannot save anything on server side.
But the size of the cookie will be around 10 KB. How to do this? Anyone have a idea?

Split the 10KB of data into multiple cookies (i.e. cookies with different names in the same domain) when saving and combine those cookie values when retrieving.
If I recall correctly, the standard size of a cookie in most modern browsers is ~4096 bytes (sometimes including the name, sometimes not) so bear this in mind when creating the cookies.
Also bear in mind that the data in the cookies could be tampered with so exercise due diligence when working with such data.

Storing persistent data in browser

For my web application, I need to store form inputs spanning across multiple pages, until I finally process/manipulate them to produce some results (its mostly formatting the data entered and presenting it in some layout). The options I think I have are -
Keep sending user's inputs to the server, store it there in some database, do the final manipulation there only, and show the result.
Store the inputs in browser's storage as the user fills the forms, and finally use this stored data to manipulate and show results.
I very much want to use the second method, and perhaps a possible way is using cookies, but I'm afraid I might just hit some upper limit of cookie data storage. I'm also open to understanding the merits of the first method, or any third method.
thanks.

Use webstorage (you can client-side store around 5MB of text or binary data)
Firefox demo: http://codebase.es/test/webstorage.html
DOM Storage is supported in these web browsers:
Internet Explorer 8
Firefox 2 for sessionStorage, 3.5 for localStorage
Safari 4
Just google for sessionStorage and localStorage objects.
Also modern webkit browsers supports client-side sql.
Edit:
I'm not sure about what you want to do but using AJAX you can store everything in javascript variables and serverside databases or sessions are a good choice.

Hitting the storage limit of the cookie could indicate you are trying to store too much on the client side. It might be prudent to store it serverside, in something like a session. The key to the session could then be stored in a cookie.
An alternative method is to not have the requests span multiple pages, and just store the data on the client side, not as a cookie, but as different form fields and/or text fields (they could be hidden). The merit of such a method is it doesnt hit the cookie limit as you have. It also makes your serverside code easier/cleaner, since it doesn't have to keep track of state (something you'd always have to do if spanning across pages, and thus the reason you are hitting the cookie limit in the first place).

You could use a small Flash Movie to store some data via Flash's Shared Memory Api or have a look at Google Gears.
Maybe also consider, that every byte you store in the cookie have to be transmitted everytime you website makes a request to the server.

Generally cookies have a max size of 4k so you could store quite a bit of data in there.
Be careful with validating all information that lives cookies - all the information resides on a client browser and can easily be manipulated by users of the site at any time.
You didn't say which platform you use. Spring Webflow does exactly the kind of form processing that you want:
http://www.springsource.org/webflow
Even if you don't use Java you could use some of the principles.
Edit: One more drawback of big/complex persistent cookies is that you have to make sure that any new code you deploy is backwards compatible with all the cookies that are out in the wild.

I would suggest storing the data in a session variable until you get to the final step rather than a cookie. I think this would be safer for your data as the user does not have direct access to the data, so you can validate as you go.