365772 - sessionStorage fails with security error when cookies are set to "ask every time" (NS_ERROR_DOM_SECURITY_ERR exception)

Status: RESOLVED DUPLICATE of bug 606655

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

Description

[Michiel]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1

the sessionStorage (and the globalStorage probably too) fails when cookies are set to "ask me every time".

Reproducible: Always

Steps to Reproduce:
1.set cookies to "ask me every time"
2.Visit the page mentioned
3.view the JS console



Actual Results:  
An error while be sent to the console:
Error: uncaught exception: [Exception... "Security error"  code: "1000" nsresult: "0x805303e8 (NS_ERROR_DOM_SECURITY_ERR)"  location: "http://channy.creation.net/work/firefox/domstorage/ Line: 38"] 

Expected Results:  
A similar warning as when a cookie is sent; that the domain wishes to store data in the browser, and wether I accept or decline such.

Comment 1

[Neil Deakin]

This was by design (see bug 341524) but it could be revisited.

Comment 2

[Michiel]

I've read the related bug, and agree with the idea (linking storage-access to cookie-access). However, the user is never warned nor asked. 

This could be resolved in various ways; most easy for the user would be to re-use the cookie-dialog to inform the user the domain/site wishes to store "some" data (either cookie or client-side data).

Another approach would be to create separate lists; it's fair to say 95% of the users will probably won't see anything related to sessionStorage and the like, as it's implemented on very few sites I suppose. This would make the workings of it all fairly complex.

Comment 3

[tavin.cole]

i'm developing a remote XUL app right now and this has become a difficulty for me.  i agree that the user should be asked what to do just as with cookies, instead of silently breaking sessionStorage and forcing the developer to trap the exception and work around it.

also, if the user chooses to "BLOCK", that's still no reason to disallow use of the sessionStorage property on the window object..  it could just be replaced with an ordinary Object instead of something that persists.  that way the developer doesn't have to write alternate code paths for when sessionStorage cannot be accessed.

Comment 4

[Thierry Lévèque]

With the latest b5, this is now also happening when cookies are set to "they expire" and "I close Firefox"
Any Keep until value.

Comment 5

[Thierry Lévèque]

This should really be fixed because it makes globalStorage totally unusable in FF3. It is always throwing the exception: [Exception... "Security error"  code: "1000" as soon as we use "globalStorage[hostname]".
 

Comment 6

[A Gaudio]

I can't update the depends/blocks, but I believe both bug 442605 and bug 389002 should depend on this (or be duped to it)- see my comments in those bugs.

Comment 7

[Nicholas C. Zakas]

Even further: if cookies are disabled, any attempt to access sessionStorage throws an error. Even though I understand the reasoning behind tying sessionStorage usage to cookies, it seems like there has be a more consistent behavior. For example, if I try to write to document.cookie while cookies are disabled, it doesn't throw an error, so why does an error occur when writing (or reading?) to sessionStorage when cookies are disabled?

I'd like to see sessionStorage updated to act more like document.cookie in that trying to read a value while cookies are disabled returns null instead of throwing an error, and trying to write to sessionStorage is just ignored. Anything but throwing an unexpected error.

Comment 8

[Nickolay_Ponomarev]

Nicholas: please file a separate bug about that. The spec is not clear on this and it would be even better if you checked if this issue was raised in the working group and how other browsers handle this cookie-disabled situation.

On the original topic, is the "Ask me every time" even in the UI in the most recent Firefox version (didn't see it)? I guess it's still supported via hidden prefs?

Comment 9

[Johnny Stenback (:jst)]

Not blocking 1.9.2 on this per discussion with Honza.

Comment 10

[ebaynegs]

this bug still seems to be affecting the latest firefox 3.6.3 on win-xp sp3

it seems to affect the HTML5 localstorage API too as well as the session storage and global storage previously mentioned.

if i set the cookie setting for "keep until" to "ask me every time"
and i run the following javascript code

  if(typeof(localStorage)!='undefined') 

i get the "Security error" error message in the error console.

Comment 11

[ebaynegs]

BTW @Nickolay_Ponomarev the "ask me every time" setting is in the UI in the latest version of firefox (3.6.3)

To access it, go to Tools/Options/Privacy/Firefox Will/Use Custom Settings for History/keep until/ask me every time

Comment 12

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Not prompting (aka "assuming ask equals silently reject", per bug 341524 comment 17) is a real nightmare, because things repeatedly, silently fail, and you have no clue why. Granted, part of this is because sites aren't catching the exception, but every "fancy" new Moz webtool site has or has had this problem (graphs, tbpl, atul's bugzilla dashboard).

If I were blocking cookies, I'd know to expect things may not work and that if something isn't working, I should relax cookie restrictions (or for sites to just let me know). It's the same when I have sites ask; if a site asks me to set a cookie and I choose to deny it and then something doesn't work, I have a very good idea why.  It's all out in the open.

With session/local/global storage, though, I get none of the contextual clues to help me understand that my preference setting is causing a problem--especially since I'm expecting to be prompted if someone wants to use storage, given my prefs setting!  Even worse, sites can't tell me I have session storage "off" or that I'm blocking their session storage requests because they see that storage is "on" and then get an exception that they're (for the most part) not expecting when they try to write to session storage.  My context clues now are "Is this site claiming to use nifty new web technologies? If so, it's probably Gecko's broken session storage prompting breaking the site, so I'd better go allow all cookies so I can use the site.", which is far less useful a context clue than having just been prompted to allow data storage.

Incidentally, there's a UI consistency problem: cookies can prompt, offline storage can prompt (and even does so by default!); why is session storage, which purports to be like cookies (or even an extension of them), not allowed to prompt?

(In reply to comment #11)
> To access it, go to Tools/Options/Privacy/Firefox Will/Use Custom Settings for
> History/keep until/ask me every time

In addition, remember that session storage is available/supported in non-Firefox applications that do expose cookie preferences by default (e.g., Camino, SeaMonkey).

Honza/Neil/jst, can we at least *confirm* this bug?  Camino would certainly appreciate a fix for this, but just confirming it would be a welcome step.

Comment 13

[Jesper]

I know this is an old thread, but instead of creating a new, I think it would be appropriate to use this one.

I can confirm that the DOM still is inaccessible in Firefox 5.0 when 1st party cookie handling is set to "ask me every time". (3rd party cookies are un-checked). Setting either "Keep till (Expire/Close Ff)" enables DOM again.

As it is right now, it is a choice between the plague and cholera, either accept all 1st party cookies or have no DOM access; If I allow all cookies to have DOM enabled, then I have no control of what is being stored in the DOM, and will have a billion cookies by the time I restart Firefox. However if I use "Ask me every time", there are several sites that I use/trust which doesn't work.

I would like to see a fix to this issue, along with an option to allow/disallow sites to access the DOM;
Some people have already mentioned some approaches, like:
If cookies are denied then dom should be denied too Or Ask with pop-op like cookies and off-line data does.

_
Jesper

Comment 14

[Ian Nartowicz]

The intention of the implementation is that "ask me every time" should mean DOM storage is not allowed.  Clearly it doesn't work.  Or actually it does work but it spams the error console while blocking sessionStorage.  This might just be bug 517778 rearing its head.

Do most people really want to be asked every time?  I vote for wontfix at this time, although a better UI for DOM storage permissions is definitely needed.

Comment 15

[Mardeg]

Remember that the prompt allows an exception to be permanently remembered. For people that have cookies disabled by default, they will likely switch to "ask me everytime" when a site doesn't work to see which cookies are trying to be set so they can add a permanent exception before switching back to disallowing all cookies *other than the exceptions*
I consider exactly the same situation would occur with DOM storage and should be handled by Firefox in the same way.

Comment 16

[Pascal Ernster]

Hi folks, just a few remarks:

1.) I can confirm this bug on Archlinux x86_64 with Firefox 11.0. If network.cookie.lifetimePolicy is set to "1"
(this is the "ask me every time" setting) and dom.storage.enabled is set to "true", accessing window.localStorage or window.sessionStorage throws an NS_ERROR_DOM_SECURITY_ERR exception. This is a fuckin showstopper, you can't use any site on blogspot or blogger.com (can't get past the loading screen with the turning gears), this affects a major German web banking site ( http://www.heise.de/-1380284 ), and a friggin lot of other sites. I think it even affects the login page of some DSL routers (ALICE IAD4421, a rebranded Arcadyan device).

2.) There's at least 4-5 other bug reports which could probably all be marked as a duplicate of this one. 
bug 389002
bug 529918 (not so sure about this one, though)
bug 659009
bug 726955
bug 748620

3.) IMHO, dom.storage.enabled should be set to "false" when the user sets the cookie lifetime policy to "always ask" as long as the necessary GUI elements to configure DOM storage seperately isn't implemented. Yes, it hurts to disable such a trendy web2.0 oh-my-gosh-I-can't-live-without-it!!1!11 buzzword feature, but it's better to have no DOM storage at all than to have a DOM storage with an undefined behaviour that makes a considerable number of websites impossible to use/read/visit.

4.) This bug clearly belongs into the "known issues" section of the release notes. I wasted several hours on finding out why the hell I couldn't read a single page on blogspot, disabling a dozen extensions, manually resetting every single **** setting I could suspect to be related to this. And I'm pretty sure I'm not the only one with a similar experience...

General note: Firefox was once (quite a few years ago) considered to be a fast, lean, efficient browser. Unfortunately, this has changed: It's full of memleaks and other nasty bugs, it feels slower and slower, it takes ages to load, it still doesn't support fuckin TLS 1.1 and 1.2, and it still crashes "when trying to start browser against a locked profile".
In short: It stinks. Now stop redecorating the living room for the 10th time, get into the basement and start diggin the **** out of it. The world doesn't need a 3D inspector for HTML code. It's a fuckin browser, not a GPU benchmark. It's called *MOZILLA* Firefox, not iD Quake 5 or Apple iWeb. It's supposed to be stable, to be rugged, to be secure. It's supposed not to crash. It's supposed to prevent my creepy tech porn neighbor from eavesdropping on me when *I* watch my porn.
Please start fixing the existing bugs instead of stacking up more and more code complexity onto a rotten base.

Comment 17

[neilr8133]

"Mandelbug style" manifestation on Firefox 14.0.1 using XP SP3 running the tutorial/demo at <http://www.w3schools.com/html5/tryit.asp?filename=tryhtml5_webstorage_session>.

Also manifests intermittently on 14.0.1 using Win7.

Originally the W3Schools demo worked but I had problems with it on my server, while checking the different cookie settings the W3Schools version stopped working in all configurations but mine started working intermittently:

"Block"  = Disallow cookies
"Ask"    = Ask me every time
"Close"  = Keep until Firefox close
"Expire" = Keep cookies until they expire

14.0.1 on XP+SP3        Block  Ask    Close  Expire
My server            :  error  error  WORKS  WORKS
W3Schools            :  error  error  error  error
W3Schools, no cookies:  error  error  error  error


13.0.1 on Win7          Block  Ask    Close  Expire
W3Schools            :  WORKS  WORKS  WORKS  WORKS


14.0.1 on Win7          Block  Ask    Close  Expire
My server            :  WORKS  error  WORKS  WORKS
W3Schools            :  WORKS  WORKS  WORKS  WORKS

Comment 18

[Ed Morley [:emorley]]

This caused several wasted hours for me today, whilst trying everything but the cookie settings to figure out why fileit had stopped working.

Even a slightly clearer failure message in the web console would be a significant improvement on the status quo.

Comment 21

[Alan Curry]

A bug report asking for a feature to work properly is a duplicate of a bug report asking for it to be removed?

I'm going to be pessimistic and assume this means we're about to lose the ability to selectively accept cookies.

Users of this feature have for many years tolerated a bad user interface (multiple simultaneous modal dialogs) and weird side effects (sessionStorage/localStorage breakage) because those inconveniences are outweighed by our dislike of unnecessary and abusive cookies. We won't be happier if it stops working completely.

Comment 22

[Honza Bambas (:mayhemer)]

Alan, please express your concerns on bug 606655.  Nobody will care about comments on this closed bug.