sessionStorage doesn't work in file:/// documents

RESOLVED FIXED

Status

()

Core
DOM
RESOLVED FIXED
6 years ago
4 years ago

People

(Reporter: KWierso, Assigned: mayhemer)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
Created attachment 587396 [details]
Test case

+++ This bug was initially created as a clone of Bug #507361 +++

Bug 507361 fixed this for localStorage, but it seems like sessionStorage still has this problem.

If I open this test file in a current Nightly build, I see the following error logged to the error console:
Timestamp: 1/10/2012 11:29:27 AM
Error: uncaught exception: [Exception... "Operation is not supported"  code: "9" nsresult: "0x80530009 (NS_ERROR_DOM_NOT_SUPPORTED_ERR)"  location: "file:///C:/Users/admin/Desktop/mytest.html Line: 11"]


If I change from using sessionStorage to using localStorage in the test file, it works just fine.

Bug 357323 was about sessionStorage, and it was duped to bug 507361, saying 357323 was fixed by 507361. (I do see a different error than what bug 357323 mentioned, but it still doesn't work for me.)
(Assignee)

Comment 1

6 years ago
This code:

http://hg.mozilla.org/mozilla-central/annotate/011e3cef6068/docshell/base/nsDocShell.cpp#l2277

needs also update to support file scheme and define a domain for it.  In that bug we made it a directory for files:

https://bugzilla.mozilla.org/attachment.cgi?id=550808&action=diff#a/dom/src/storage/nsDOMStorageDBWrapper.cpp_sec2

I don't think that having a generic way of getting a domain would be useful, since this is only valid use case for DOM storage.

Would be nice to have just a single place of the code that would get the 'domain' for storage mapping.  Now we will duplicate it.  Probably the storage manager will be the place.
Assignee: nobody → honzab.moz
Status: NEW → ASSIGNED

Comment 2

6 years ago
We are having the same problem, seems that localStorage for "file://" domains was fixed in 8, but not sessionStorage.
(Assignee)

Comment 3

6 years ago
Can please anyone test with latest nightly builds whether this has been fixed?  I've landed bug 495337 that might well fixed this bug.
(Reporter)

Comment 4

6 years ago
(In reply to Honza Bambas (:mayhemer) from comment #3)
> Can please anyone test with latest nightly builds whether this has been
> fixed?  I've landed bug 495337 that might well fixed this bug.

My test case attached to the bug no longer logs any errors, and it alerts "N,Y,0".
So I guess it works?
(Assignee)

Comment 5

6 years ago
(In reply to Wes Kocher (:KWierso) (Jetpack Bugmaster) from comment #4)
> (In reply to Honza Bambas (:mayhemer) from comment #3)
> > Can please anyone test with latest nightly builds whether this has been
> > fixed?  I've landed bug 495337 that might well fixed this bug.
> 
> My test case attached to the bug no longer logs any errors, and it alerts
> "N,Y,0".
> So I guess it works?

Thanks!  I will close this bug for now.

If the issue appears again then PLEASE FILE NEW BUGS RATHER THEN REOPENING THIS ONE.
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Component: DOM: Mozilla Extensions → DOM
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.