Closed
Bug 517778
Opened 15 years ago
Closed 7 years ago
Accessing sessionStorage throws an error when cookies are disabled
Categories
(Firefox :: General, defect)
Tracking
()
RESOLVED
WONTFIX
Tracking | Status | |
---|---|---|
blocking2.0 | --- | - |
People
(Reporter: webkit, Unassigned)
References
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.14) Gecko/2009082707 Firefox/3.0.14 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.14) Gecko/2009082707 Firefox/3.0.14 (.NET CLR 3.5.30729)
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 suppose there are two real questions:
a) Should access to sessionStorage be tied to cookies at all?
b) If yes to a, is it expected to throw an error when disabled? Or should it fail silently like cookies?
Reproducible: Always
Steps to Reproduce:
1. Disable cookies
2. Try to write to sessionStorage
3. Witness JavaScript error
Actual Results:
JavaScript error is thrown
Expected Results:
No JavaScript error is thrown
Safari's implementation of sessionStorage is not tied to cookies at all. Regardless of whether or not cookies are disabled, sessionStorage continues to work.
Updated•15 years ago
|
Assignee: nobody → honzab.moz
Updated•15 years ago
|
Flags: blocking-firefox3.6?
Comment 1•15 years ago
|
||
I think we need to figure out what component this sort of stuff should land in, and then also how we're going to treat the various offline storage pieces (as cookies, as something more than cookies, etc).
(FWIW, they're currently treated like cookies because they act a lot like cookies, and can be used for a lot of the same purpose as cookies.)
blocking2.0: --- → ?
Flags: blocking-firefox3.6? → blocking-firefox3.6-
See also bug 527970, about sessionStorage throwing when it itself is off, and bug 449981/bug 506692 about storage-as-cookies UI.
Updated•14 years ago
|
blocking2.0: ? → -
Comment 3•14 years ago
|
||
Right now it's tied to cookies because it was easy to do it that way, but it should change.
Ideally we'd have separate prefs controlling each storage mechanism (cookies, storage, IndexedDB, cache), and they'd all be tied together in the UI with some kind of "disable all persistent storage" option. But people could override that by enabling (perhaps by UI, or about:config) the various pieces.
With regard to throwing -- document.cookie can fail for reasons other than cookies being disabled, f.e. prompting, a bad cookie string, cookie being already expired etc. So unless we throw in more circumstances, it doesn't make much sense to throw if they're blanket disabled.
Depending on storage's failure modes, we could change the behavior there, but changing it for cookies would be a big compatibility concern.
Updated•14 years ago
|
Version: unspecified → 3.0 Branch
Updated•11 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•9 years ago
|
Assignee: honzab.moz → nobody
Comment 4•7 years ago
|
||
We will update our communication around this permission to say "Site Data and Cookies" (in a dependency of bug 1421690) instead of offering separate permissions for the different storage options.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•