meyerweb.com

Skip to: site navigation/presentation
Skip to: Thoughts From Eric

Firefox Failing localStorage Due to Cookie Policy

I recently stumbled over a subtle interaction between cookie policies and localStorage in Firefox.  Herewith, I document it for anyone who might run into the same problem (all four of you) as well as for you JS developers who are using, or thinking about using, locally stored data.  Also, there’s a Bugzilla report, so either it’ll get fixed and then this won’t be a problem or else it will get resolved WONTFIX and I’ll have to figure out what to do next.

The basic problem is, every newfangled “try code out for yourself” site I hit is just failing in Firefox 11 and 12.  Dabblet, for example, just returns a big blank page with the toolbar across the top, and none of the top-right buttons work except for the Help (“?”) button.  And I write all that in the present tense because the problem still exists as I write this.

What’s happening is that any attempt to access localStorage, whether writing or reading, returns a security error.  Here’s an anonymized example from Firefox’s error console:

Error: uncaught exception: [Exception... "Security error"  code: "1000" nsresult: "0x805303e8 (NS_ERROR_DOM_SECURITY_ERR)"  location: "http://example.com/code.js Line: 666"]

When you go to line 666, you discover it refers to localStorage.  Usually it’s a write attempt, but reading gets you the same error.

But here’s the thing: it only does this if your browser preferences are set so that, when it comes to accepting cookies, the “Keep until:” option is set to “ask me every time”.  If you change that to either of the other two options, then localStorage can be written and read without incident.  No security errors.  Switch it back to “ask me every time”, and the security errors come back.

Just to cover all the bases regarding my configuration:

  1. Firefox is not in Private Browsing mode.
  2. dom.storage.default_quota is 5120.
  3. dom.storage.enabled is true.

Also:  yes, I have my cookie policy set that way on purpose.  It might not work for you, but it definitely works for me.  “Just change your cookie policy” is the new “use a different browser” (which is the new “get a better OS”) and it ain’t gonna fly here.

To my way of thinking, this behavior doesn’t conform to step one of 4.3 The localStorage attribute, which states:

The user agent may throw a SecurityError exception instead of returning a Storage object if the request violates a policy decision (e.g. if the user agent is configured to not allow the page to persist data).

I haven’t configured anything to not persist data—quite the opposite—and my policy decision is not to refuse cookies, it’s to ask me about expiration times so I can decide how I want a given cookie handled.  It seems to me that, given my current preferences, Firefox ought to ask me if I want to accept local storage of data whenever a script tries to write to localStorage.  If that’s somehow impossible, then there should at least be a global preference for how I want to handle localStorage actions.

Of course, that’s all true only if localStorage data has expiration times.  If it doesn’t, then I’ve already said I’ll accept cookies, even from third-party sites.  I just want a say on their expiration times (or, if I choose, to deny the cookie through the dialog box; it’s an option).  I’m not entirely clear on this, so if someone can point to hard information on whether localStorage does or doesn’t time out, that would be fantastic.  I did see:

User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user.

…from the same section, which to me sounds like localStorage doesn’t have expiration times, but maybe there’s another bit I haven’t seen that casts a new light on things.  As always, tender application of the Clue-by-Four of Enlightenment is welcome.

Okay, so the point of all this: if you’re getting localStorage failures in Firefox, check your cookies expiration policy.  If that’s the problem, then at least you know how to fix it—or, as in my case, why you’ll continue to have localStorage problems for the next little while.  Furthermore, if you’re writing JS that interacts with localStorage or a similar local-data technology, please make sure you’re looking for security exceptions and other errors, and planning appropriate fallbacks.

Eight Responses»

    • #1
    • Comment
    • Wed 25 Apr 2012
    • 1952
    Sean Hogan wrote in to say...

    Thank you. That’s important to know for js devs.

    • #2
    • Comment
    • Thu 26 Apr 2012
    • 1137
    Eric Meyer wrote in to say...

    Thank YOU, Sean, for reminding me that developers are another important audience for this sort of thing. I’ve updated the post accordingly.

    • #3
    • Comment
    • Thu 26 Apr 2012
    • 2108
    tom jones wrote in to say...

    until this is fixed, and/or if this is a problem only on a couple of important sites, you can add them to the “exceptions” section with the option to always “allow” for those domains. HTH

    • #4
    • Comment
    • Wed 1 Aug 2012
    • 1426
    Izzy wrote in to say...

    There’s a work around available, as I just discovered: I use the Firefox addon Cookie Button, which makes it easy to set a policy per-site. So I set it to accept from the sites I need — and to ask for every other. Seems to work fine. I wasn’t aware this has to do with LocalStorage until reading your article (I had trouble with stackexchange) — thanks to this I was able to solve my problem!

    • #5
    • Comment
    • Wed 1 Aug 2012
    • 2242
    Eric Meyer wrote in to say...

    Excellent point, Izzy. I’ve started doing the same with a combination of Advanced Cookie Manager and CS Lite Mod, but didn’t think to come back here to document the workaround. Thanks!

    • #6
    • Comment
    • Thu 2 Aug 2012
    • 0242
    Izzy wrote in to say...

    You are welcome, Eric! I also posted this solution (including a reference to this page here) on the Stackoverflow Meta section, as it might affect a lot of people at stackexchange (I was one of them). Unfortunately, they do not seem to like it (got downvoted ;) — but who cares. The information is there for those in need, that’s the important thing. So again thanks to you for bringing me on the right track!

    • #7
    • Comment
    • Sun 12 Aug 2012
    • 1329
    George K. wrote in to say...

    Thanks for shedding light! was puzzled why caniuse.com has stopped working in my FF on paranoic cookie settings.

    • #8
    • Comment
    • Fri 28 Dec 2012
    • 1522
    Todd Keup wrote in to say...

    I found it quite odd that I just went through the exact same steps (reading the Storage specs, etc.) and analyzing this very issue before I found myself here on your site! I wish I would have taken the time to troubleshoot this back in April when I first ran into the issue. A recent task forced the issue and I too am a developer and ultimately I had to figure out what was going on with this security message I was receiving. With my new keyword (localStorge) to use for search I came across your bugzilla report and this post. Thanks. I thought it might be helpful for any future readers (developers) to know that you can put in a try/catch block and incorporate your own handler. I know that the try/catch solution has been mentioned in the bug reports and elsewhere but I wanted to add that the Gecko docs have an example workaround handler or if you are using Modernizr you can load one of the polyfills from there instead. This is by no means a working solution but it should get you started in the proper direction if you find yourself in the same situation:


    try {
    localStorage.foo = localStorage.foo == 'undefined'
    ? 'true'
    : localStorage.foo
    ;
    } catch (e) {
    // set your own handler or use a polyfill:
    // https://developer.mozilla.org/en-US/docs/DOM/Storage OR
    // https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-browser-Polyfills
    }

Leave a Comment

Line and paragraph breaks automatic, e-mail address required but never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>



Remember to encode character entities if you're posting markup examples! Management reserves the right to edit or remove any comment—especially those that are abusive, irrelevant to the topic at hand, or made by anonymous posters—although honestly, most edits are a matter of fixing mangled markup. Thus the note about encoding your entities. If you're satisfied with what you've written, then go ahead...


April 2012
SMTWTFS
March May
1234567
891011121314
15161718192021
22232425262728
2930  

Sidestep

Feeds

Extras