I understand that changing the preference to the later has fixed this issue? Or are you still asking about this error: "why does sessionStorage.getItem fail with SecurityError: The operation is insecure"

My workaround is not an acceptable solution. I wish to be prompted for my cookie preference for every site I visit and I also want to be prompted for local storage use.

That is the problem with DOM Storage or DOM indexedDB: there is no control over who is allowed to use them. I disabled both because of that.

I do have control over cookies. I disable them by default and make exceptions for those that I need. Some sites that I visit every day I allow to set persistent cookies. Others that I visit seldom I allow only session cookies. If a site does not absolutely need cookies, I do not bother allowing them. I have an extension that makes changing cookie permissions for the site I am visiting convenient. The advantage to this approach is that I do not need to delete any cookies, since I have only those that I need.

I don't think this is a recent issue, although the error message in the console may have changed at some point. Are you finding that this affects a lot of sites you use?

The permission to use DOM storage has been linked to the cookie permission since 2006, since DOM storage can be used similarly to cookies. As a result, scripts that do not have permission to set cookies and try to use DOM storage die with a error. My speculation on why this happens with your setting is that cookies are treated as blocked unless and until you select a different permission in the dialog, and therefore DOM storage also is initially blocked.

Bugs were filed in 2007 and 2012 to try to improve the situation, for example, by having a clearer error message or a user interface for local storage permission, rather than having web apps suffer a silent failure.

• Bug #365772 – sessionStorage fails with security error when cookies are set to "ask every time" (NS_ERROR_DOM_SECURITY_ERR exception)

• 748620 – When cookie expiration is set to ask every time, localStorage throws a security exception.

• Regarding using the bug tracking system, see:
  • Bugzilla Etiquette
  • Voting

I don't know what the solution to this is from the browser side. For example, it would be convenient for users with your setting if either of these were possible:

• Firefox might pause the script in the site to wait and see what you choose before trying to access DOM storage in the blocked state. Not all scripts will complete correctly if paused.

• Firefox might allow the site to use DOM storage temporarily and if you keep the site blocked, clear what the site wrote to storage and block further access.

If I could influence web app writers, since this issue hasn't gone away for 9 years and probably won't be changed in the near future, I would suggest they test for ability to write cookies before using DOM storage.

jscher2000, With only session or temporary cookies being allowed, does the stuff in DOM storage disappear when the browser is closed, as the cookies do? Does what you said also apply to SeaMonkey?

finitarry said

With only session or temporary cookies being allowed, does the stuff in DOM storage disappear when the browser is closed, as the cookies do? Does what you said also apply to SeaMonkey?

I do not know the answer to either of those questions. Definitely worth a test.

I tried a test using Panopticlick. The DOM storage does seem to depend on cookie permissions, and with SeaMonkey. Figuring out whether the stored items disappear with disappearing cookies is a lot more tricky. I have Better Privacy installed and set to remove DOM storage items, and am not about to turn that off.