User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.14) Gecko/2009082707 Firefox/3.0.14 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.14) Gecko/2009082707 Firefox/3.0.14 (.NET CLR 3.5.30729) if cookies are disabled, any attempt to access sessionStorage throws an error. Even though I understand the reasoning behind tying sessionStorage usage to cookies, it seems like there has be a more consistent behavior. For example, if I try to write to document.cookie while cookies are disabled, it doesn't throw an error, so why does an error occur when writing (or reading?) to sessionStorage when cookies are disabled? I suppose there are two real questions: a) Should access to sessionStorage be tied to cookies at all? b) If yes to a, is it expected to throw an error when disabled? Or should it fail silently like cookies? Reproducible: Always Steps to Reproduce: 1. Disable cookies 2. Try to write to sessionStorage 3. Witness JavaScript error Actual Results: JavaScript error is thrown Expected Results: No JavaScript error is thrown Safari's implementation of sessionStorage is not tied to cookies at all. Regardless of whether or not cookies are disabled, sessionStorage continues to work.

I think we need to figure out what component this sort of stuff should land in, and then also how we're going to treat the various offline storage pieces (as cookies, as something more than cookies, etc). (FWIW, they're currently treated like cookies because they act a lot like cookies, and can be used for a lot of the same purpose as cookies.)

See also bug 527970, about sessionStorage throwing when it itself is off, and bug 449981/bug 506692 about storage-as-cookies UI.

Right now it's tied to cookies because it was easy to do it that way, but it should change. Ideally we'd have separate prefs controlling each storage mechanism (cookies, storage, IndexedDB, cache), and they'd all be tied together in the UI with some kind of "disable all persistent storage" option. But people could override that by enabling (perhaps by UI, or about:config) the various pieces. With regard to throwing -- document.cookie can fail for reasons other than cookies being disabled, f.e. prompting, a bad cookie string, cookie being already expired etc. So unless we throw in more circumstances, it doesn't make much sense to throw if they're blanket disabled. Depending on storage's failure modes, we could change the behavior there, but changing it for cookies would be a big compatibility concern.

We will update our communication around this permission to say "Site Data and Cookies" (in a dependency of bug 1421690) instead of offering separate permissions for the different storage options.