Last Comment Bug 748620 - When cookie expiration is set to ask every time, localStorage throws a security exception
: When cookie expiration is set to ask every time, localStorage throws a securi...
Status: RESOLVED DUPLICATE of bug 365772
:
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: 12 Branch
: x86 Mac OS X
: -- normal with 12 votes (vote)
: ---
Assigned To: Honza Bambas (:mayhemer)
:
Mentors:
: 748617 781447 824138 1028153 (view as bug list)
Depends on: 600307
Blocks: 832732
  Show dependency treegraph
 
Reported: 2012-04-24 18:06 PDT by Eric A. Meyer
Modified: 2016-01-06 10:47 PST (History)
36 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Test from duplicate (458 bytes, text/html)
2012-04-25 00:16 PDT, :Ms2ger (⌚ UTC+1/+2)
no flags Details

Description Eric A. Meyer 2012-04-24 18:06:58 PDT
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 1 Jordan Gray 2012-04-24 18:15:21 PDT
*** Bug 748617 has been marked as a duplicate of this bug. ***
Comment 2 Eric A. Meyer 2012-04-24 18:23:45 PDT
Sorry, extra data point: Private Browsing is NOT enabled during any of this testing.
Comment 3 Matthias Versen [:Matti] 2012-04-24 18:44:33 PDT
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 2012-04-24 19:27:35 PDT
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 (⌚ UTC+1/+2) 2012-04-25 00:16:13 PDT
Created attachment 618176 [details]
Test from duplicate
Comment 6 Boris Zbarsky [:bz] 2012-04-25 07:56:20 PDT
> 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 2012-04-25 11:10:17 PDT
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 2012-04-25 12:46:06 PDT
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 2012-04-26 07:27:59 PDT
Addendum: the current behaviour was determined as the resolution to bug 341524.
Comment 10 Eric A. Meyer 2012-04-26 08:34:11 PDT
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 2012-05-02 13:41:32 PDT
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 2012-06-02 16:30:56 PDT
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 2012-06-06 11:40:34 PDT
(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 2012-06-06 11:56:22 PDT
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 2012-06-11 15:44:44 PDT
(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 2012-06-11 15:48:00 PDT
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 17 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2012-07-08 05:02:23 PDT
*** Bug 771890 has been marked as a duplicate of this bug. ***
Comment 18 Boris Zbarsky [:bz] 2012-09-07 13:33:46 PDT
*** Bug 781447 has been marked as a duplicate of this bug. ***
Comment 19 Jesús 2012-09-29 13:07:14 PDT
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 2012-11-25 05:51:49 PST
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 2012-12-15 23:32:26 PST
Is this a dup of bug 365772?
Comment 22 Jesse Ruderman 2012-12-15 23:37:13 PST
(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 23 Jim Garrison 2012-12-23 10:21:20 PST
*** Bug 824138 has been marked as a duplicate of this bug. ***
Comment 24 Jim Garrison 2012-12-23 10:30:31 PST
As noted in Bug 824138 this also breaks www.icloud.com
Comment 25 Jesús 2013-01-20 02:52:49 PST
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) 2013-01-21 07:24:27 PST
-> me
Comment 27 Danek Duvall 2013-07-11 09:21:35 PDT
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 2014-03-10 06:47:57 PDT
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 2014-04-26 05:47:10 PDT
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 2014-07-15 03:47:07 PDT
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 2014-10-26 05:42:24 PDT
Happens on Linux with first-party-only exception for the site (cookies otherwise blocked) in Firefox 33.
Comment 32 patrik.nyborg 2014-11-04 12:09:12 PST
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 33 Nickolay_Ponomarev 2014-11-09 16:25:26 PST
*** Bug 1028153 has been marked as a duplicate of this bug. ***
Comment 34 Jesús 2014-12-10 13:40:06 PST
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] 2015-05-01 13:36:24 PDT
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 2015-12-16 08:58:33 PST
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.
Comment 37 Honza Bambas (:mayhemer) 2016-01-06 10:47:01 PST

*** This bug has been marked as a duplicate of bug 365772 ***

Note You need to log in before you can comment on or make changes to this bug.