Closed Bug 771890 Opened 12 years ago Closed 1 month ago

localStorage throws a cryptic security error when cookies are disabled

Categories

(Core :: Storage: localStorage & sessionStorage, defect, P5)

15 Branch
x86_64
Windows 7
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: kael, Unassigned)

Details

Attachments

(1 file)

Attached image Screenshot
In nightly (15.0a1 (2012-06-04)), localStorage fails with a security error. I can reproduce this by hitting basically any page and then typing 'localStorage' in the developer console. (Scripts using localStorage fail too). Tested against a local server, along with real websites.
Just realized I'm on the nightly-profiling channel. It looks like maybe updating is broken for that channel, or this is a bug introduced by the profiler?
OK, this is caused by having third-party cookies disabled. It should maybe be made clear that the cookies setting controls localStorage.
Severity: blocker → major
Summary: localStorage nonfunctional in Nightly → localStorage throws a cryptic security error when cookies are disabled
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Er.. comment 2 and bug 748620 are not the same.  Just the third-party setting should not affect localStorage last I checked.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Kevin, is this a regression?
See bug 536509. Looks intentional to me.
Except that the patch there hasn't actually landed yet. Spooky.
I don't think this is a regression - I had changed my history preferences earlier in the day after seeing some reports about private browsing mode disabling JS profiling, and forgot to switch it back to its original state. 

I can reproduce the same behavior in Aurora once I change the pref. I think the point of confusion was just that it was unclear to me that "Never remember history" actually stores cookies, so when I went in to customize my settings (and disable private browsing mode to try and get JS profiling working), I unchecked the cookies checkbox.

It doesn't seem like a dupe of 748620, but it seems very similar - maybe both issues are caused by a common code path?
Kevin, so just to make sure you have cookies generally enabled but third-party cookies disabled?

I have third-party cookies disabled, and localStorage works just fine for me in a 2012-07-06 nightly is why I'm asking.
Sorry, I think I misread the UI in my earlier comment. #8 is accurate in that I was using the main checkbox for cookies (instead of the narrower third-party one).
Ah.  Yeah, ok.  Then I think this is invalid as originally filed: no cookies mean you don't want tracking stuff or data stored, and localStorage is just another way to do that...

I do think that we should improve the message text, though (the current summary of this bug).
Status: REOPENED → NEW
Calling local storage a cookie is a strange interpretation of the idea of a cookie. I understand that maybe cookies being disabled has to kill everything else to stop the onslaught of evil advertisers, but in that case, the setting should say what it actually does. :D

And yeah, if the exception said the actual reason why it failed, I would have instantly realized what the problem was.
The idea of "cookie" from a user's point of view is "some data a website stores on my hard drive"...  That's what pretty much every non-technical definition of "cookie" talks about, including http://en.wikipedia.org/wiki/HTTP_cookie

See also http://en.wikipedia.org/wiki/Zombie_cookie and so forth: the term is used for more than just HTTP cookies at this point....
Yeah sure, disabling cookies should disable localStorage, but certainly not throws a security exception when trying to access localStorage.
What should be the correct behavior?
LocalStorage also throws an error when "Ask everytime" is enabled for all cookies. I have the problem with facebook messages which won't show up unless I disable dom.storage. See bug 365772 and bug 748620.
I'm posting here the comments I left on bug 748620 since this seems to be specific about the error it throws, and the other may be specific to implement a UI similar to the cookie preference.

On that bug there are examples of sites being partially or completely broken because of this security exception

----
From bug 748620 comment 11:

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.

----
From bug 748620 comment 14:

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.
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.
Priority: -- → P5
Component: DOM → DOM: Core & HTML

Hey Katelyn,
Can you still reproduce this issue or should we close it?

Flags: needinfo?(kg)

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Severity: major → --
Component: DOM: Core & HTML → Storage: localStorage & sessionStorage

(In reply to Andrei Purice from comment #18)

Hey Katelyn,
Can you still reproduce this issue or should we close it?

I'll take the non-answer as works for me. In the opposite case please file a new bug with new/updated STR. Thank you for your support!

Status: NEW → RESOLVED
Closed: 12 years ago1 month ago
Flags: needinfo?(kg)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.