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

Status: RESOLVED DUPLICATE of bug 365772

(Core :: DOM: Core & HTML, defect)

Description

[Eric A. Meyer]

User Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en; rv:1.9.2.28) Gecko/20120308 Camino/2.1.2 (like Firefox/3.6.28)
Build ID: 20120308211433

Steps to reproduce:

0. Launched Firefox 12.
1. Went to a remote web site (ex. http://w3.org/).
2. Opened the console (opt-cmd-K).
3. Typed "localStorage.foo = 'bar';".


Actual results:

Received via the console:

[20:46:44.950] [Exception... "Security error"  code: "1000" nsresult: "0x805303e8 (NS_ERROR_DOM_SECURITY_ERR)"  location: "Web Console Line: 1"]



Expected results:

That’s where it gets interesting.  The answer is either that the console should have returned "bar", or else Firefox should have asked me what I wanted to do.

Note that dom.storage.default_quota = 5120 and dom.storage.enabled = true.  The problem is that while I have cookies set to be accepted, including third party sites, I have “Keep until:” set to “ask me every time”.  If I change it to either “they expire” or “I close Firefox” and repeat steps 0-3, the console returns "bar".  As soon as I change it back to “ask me every time”, the security exception is thrown.

Further, the error is thrown on any attempt to access localStorage, either reading or writing.  You can change step 3 above to:

3. Typed "localStorage.foo;".

…and get the same results (albeit with a slightly set of different expected results).

This seems to violate http://www.w3.org/TR/webstorage/#dom-localstorage step 1, because no policy decision has been violated by the attempt to set localStorage data: my policy decision is to ask me for confirmation of expire times.  No inquiry is made; Firefox simply fails.

Ideally, Firefox would ask me if I wish to allow data to be stored locally.  Less ideally, there would be a preference setting letting me indicate globally how I want to handle localStorage (yes or no).  Even less ideally, Firefox would simply accept the locally stored data on the grounds that I have given permission to set cookies, even though I want to be asked about expire times.

Of course, if localStorage data does not have expire times (and http://www.w3.org/TR/webstorage/#dom-localstorage seems to indicate that it should not) then the “Keep until:” would seem to be irrelevant and causing this error is an error, but I have a lot less certainty about that.

Comment 2

[Eric A. Meyer]

Sorry, extra data point: Private Browsing is NOT enabled during any of this testing.

Comment 3

[Matthias Versen [:Matti]]

The "ask me every time" option isn't supported by Gecko (from a comment from bz) and should not be exposed by the UI.
That the localstorage is affected by the cookie setting is afaik by design.

Comment 4

[Eric A. Meyer]

Well, it *is* exposed by the UI—I can send you screenshots—and it’s screwing with localStorage.  The dependency between the two is not just supported, but so far as I can tell required, but in this case Firefox appears to be falling down.

(Also, WHY is it not supported?  I don’t want to be blindly accepting every damn cookie sites try to shove down my throat.  “Ask every time” lets me decide which to accept and which to deny.)

Comment 5

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Attachment: Test from duplicate

Comment 6

[Boris Zbarsky [:bzbarsky]]

> Also, WHY is it not supported? 

Because it requires synchronous UI interaction during network transactions and the current implementation is fundamentally broken because necko is not designed around this sort of thing.  If you have this option turned on, it _will_ cause your browser to crash every so often.  Use at your own risk.

Comment 7

[Eric A. Meyer]

Okay, I’ll accept that risk for the return of having control over cookies.  How about the bug here, though?  Should Firefox be honoring my “accept all cookies” setting and accessing localStorage, or not?

Comment 8

[Jordan Gray]

The current setting is understandable in context. Local storage overlaps significantly with cookies in terms of use cases and privacy concerns; however, because you can't set an expiry date for data in local storage, Firefox errs on the side of more privacy. If it didn't, tracking cookies could just be replaced with local storage where available. (I know developers who work for affiliate networks, and they would alredy be doing this if it were possible.)

Unfortunately, this approach breaks many sites for reasons that most users won't be able to figure out, and can't fix without changing their global cookie settings. This isn't ideal.

The proposed alternative, prompting the user to decide if a domain should be allowed to use local storage on their computers, seems obvious and ideal but will increase instability—also undesirable.

However, I think we can have our cake and eat it here. How about this: when a site tries to set a key in local storage, throw an exception and continue loading, but also display an information bar (as is already done with pop ups) noting that the page wants to save information locally, and allowing them to add the domain to a whitelist? (Aside: a similar approach has been suggested for general cookie handling when expiry is set to "ask me every time" in bug 427184.)

Some sites will still break, albeit temporarily, and we would need to consider new UI to give access to the local storage whitelist, but I think it is a more graceful approach than the current one and should avoid introducing instability by synchronously interrupting an ongoing network transaction.

Comment 9

[Jordan Gray]

Addendum: the current behaviour was determined as the resolution to bug 341524.

Comment 10

[Eric A. Meyer]

Thanks for the additional information, Jordan!  I’m not sure I agree with the reasons in 341524 but it’s really helpful to see the discussion.

I would be fine with this being handled as suggested in bug 427184.  It seems like a reasonable compromise, even if it means users like me might get a broken site while saying “yes” to cookies/local data storage and then have to reload.  My fingers know cmd-R very well…

Comment 11

[Jesús]

Should we reopen bug 599479 ? It's OK for localStorage to return null or undefined when cookies are disabled, but it's not acceptable to throw an error when accessing "window.localStorage" for reading.

It's breaking some sites that rely on localStorage being null when user disallows persistent data storage and don't expect it to throw an error, since accessing any variable in the window scope, even if not defined, shouldn't throw an error and it's a very common practice. This may pass unnoticed for many developers since it's not usual that users have their cookies completely disabled, and as I said, throwing an exception is unexpected. The exception just stops the load of the rest of the script.

Comment 12

[Mark]

I'm experiencing this problem as of this last week when using facebook messages and chat. Setting 'dom.storage.enabled' to false lets me keep my "Ask me every time" cookie setting and also allows facebook chat and messages to function.

Comment 13

[Chris J]

(In reply to Mark from comment #12)
> I'm experiencing this problem as of this last week when using facebook
> messages and chat. Setting 'dom.storage.enabled' to false lets me keep my
> "Ask me every time" cookie setting and also allows facebook chat and
> messages to function.

I've had the same issue with FB, and either changing my cookie settings (as previously noted in this thread) or Mark's suggestion of disabling local storage has fixed the problem.

Given FB is such a huge user-target, I'd be suprised if other users haven't bumped into this problem: the solution's rather non-intuitive and has had be scouting through the FF error log and google to ultimately end up here (after various google incantations) to find the solution, short of using a different browser. 

Jordan's suggestion in #8 (display an information bar) would seem to be a neat solution from the user perspective

Comment 14

[Jesús]

Local storage being unavailable is not a critical thing. Or at least when the web page could tell the user to enable it or use a different Browser. The problem here is that an error is thrown when the web page attempts to check if Local storage is actually available in the browser, breaking all the scripts.

I'd suggest to raise the priority of this bug and fixing it by simply making the getter of window.localStorage to return null or undefined and not throwing an error (as explained in comment #11). That would fix those errors on web pages. And then, on a separate bug, request for some sort of propmt for the user to accept or decline the localStorage availability for the current domain, as it works with cookies.

Comment 15

[Sebastian Wiesinger]

(In reply to Mark from comment #12)
> I'm experiencing this problem as of this last week when using facebook
> messages and chat. Setting 'dom.storage.enabled' to false lets me keep my
> "Ask me every time" cookie setting and also allows facebook chat and
> messages to function.

I'm seeing the same problem. Setting 'dom.storage.enabled' to false also fixed it for me. I then reenabled dom.storage and it still works right now.

Comment 16

[Sebastian Wiesinger]

Btw. I just spent 2 hours debugging this which included resetting my profile. A "normal" user would never find the source of this problem. Please make this obvious for the user, as I was tempted to switch to chrome (which indeed I did to read my Facebook messages).

Comment 19

[Jesús]

Another site completely unusable because LocalStorage throwing the following error just when executing the following code:

M=window.localStorage&&window.JSON&&window.JSON.stringify

Error: SecurityError: The operation is insecure.
Source: http://caniuse.com/js.php
Line: 48

URL: http://caniuse.com/#feat=css-counters

Comment 20

[Jesús]

Another site with the same problem: Blogger when the blog owner has enabled Dynamic Views: http://dynamicviewstest.blogspot.com/

A user script used on Wikipedia also breaks because of this bug: http://en.wikipedia.org/wiki/User_talk:Cacycle/wikEd#Error:_SecurityError:_The_operation_is_insecure

And a script of MediaWiki had to explicitly include a check for window.sessionStorage inside a try-catch block because of this: https://gerrit.wikimedia.org/r/#/c/27923/2/resources/mediawiki.page/mediawiki.page.search.js

Really, it doesn't do a great job in favor of web standarization if it acts in a non-standard way.

Comment 21

[Jesse Ruderman]

Is this a dup of bug 365772?

Comment 22

[Jesse Ruderman]

(In reply to Matthias Versen (Matti) from comment #3)
> The "ask me every time" option isn't supported by Gecko (from a comment from
> bz) and should not be exposed by the UI.

Removing it from the UI is bug 469260.

Comment 24

[Jim Garrison]

As noted in Bug 824138 this also breaks www.icloud.com

Comment 25

[Jesús]

This breaks also https://mega.co.nz/

Can anyone pleas change the status of this bug from UNCONFIRMED to NEW? Also it seems a pretty simple thing to fix, I don't understand why it's taking too long. It only needs to not throw a damn exception and just return null or undefined as every other browser do!

I'd really want to fix it myself but I'm not very familiar with C to debug and code a patch for it.

Comment 26

[Honza Bambas (:mayhemer)]

-> me

Comment 27

[Danek Duvall]

Never saw this with facebook, but started seeing it with feedly.  I really want a solution where I can limit the number of cookies that I get (and which sites get to set them), but still allow sites I want to interact with to work.  Perhaps there's some extension that will help with the cookie management?

Comment 28

[Mardeg]

This has shown up as the cause of play buttons not showing up in the iView player at http://iview.abc.net.au
See http://www2b.abc.net.au/tmb/Client/Message.aspx?b=98&m=32193&ps=50&dm=2

Comment 29

[Jesús]

Another broken website: http://jshint.com/

Error: SecurityError: The operation is insecure.

The "configure" link does not work. Anything you paste there isn't analyzed.

Comment 30

[jman]

Happens to on Firefox 30/Linux with these settings:
http://imgur.com/UAgAg4f

Found a workaround, though: if you explicitely allow the site in "Exceptions" the problem does not show up.

Comment 31

[Ian Nartowicz]

Happens on Linux with first-party-only exception for the site (cookies otherwise blocked) in Firefox 33.

Comment 32

[patrik.nyborg]

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Breaks the national weather site in Sweden:
http://www.smhi.se - Swedish Meteorological and Hydrological Institute

Comment 34

[Jesús]

Another website that doesn't work: any trello.com workspace
 example: https://trello.com/b/DWuSeWBE/mobile-web-developers-backlog

Firefox 34.0.5

Comment 35

[Mike Pennisi [:jugglinmike]]

I maintain a white list of allowed domains for cookies. This works as expected for cookies, but Firefox ignores the white list for localStorage references--it throws a SecurityError for every site I visit.

Many applications fail to function without localStorage, forcing me to disable my security policy or use a separate browser.

Here is my configuration:

[ ] Always use private browsing mode
    [x] Remember my browsing and download history
    [x] Remember search and form history
    [ ] Accept cookies from sites
    [ ] Clear history when Firefox closes

And my environment information:

Firefox 37.0.2
Ubuntu 14.04 LTS

Comment 36

[ashley]

I must say as a JS developer, throwing JS exceptions on storage when certain browser settings are changed is incredibly inconvenient!

Few developers expect exceptions to be thrown when accessing storage, and few developers test with every combination of browser settings. So this just makes it really easy to write broken code.

If the user opts out of accepting cookies from sites, just use temporary storage in memory that is thrown away as soon as you navigate away. Then websites keep working and the user's privacy settings are still respected.