Can't access localStorage from chrome:// (exception: NS_ERROR_NOT_AVAILABLE - [nsIDOMStorageWindow.localStorage])

RESOLVED DUPLICATE of bug 495337

Status

()

Core
DOM
RESOLVED DUPLICATE of bug 495337
8 years ago
2 years ago

People

(Reporter: Adam Christian, Assigned: mayhemer)

Tracking

Trunk
Points:
---
Bug Flags:
blocking1.9.2 -

Firefox Tracking Flags

(blocking2.0 -, status2.0 wanted)

Details

Attachments

(2 attachments)

(Reporter)

Description

8 years ago
Created attachment 380785 [details]
Mozmill test case

From mozmill (firefox addon) I can access all of the localStorage components I need to drive it, except the length attribute.

Attaching mozmill test file. (this depends on some other files to run correctly, will update the bug when I get them checked into HG)
(Reporter)

Comment 1

8 years ago
Error:

fail :: Component is not available
message: Component is not available
QueryInterface: function QueryInterface() { [native code] }
result: 2147746065
name: NS_ERROR_NOT_AVAILABLE
filename: file:///private/var/folders/YO/YOAvf2hSGt0+VnBIAKuImE+++TM/-Tmp-/tmpZZ1QY6.mozrunner/extensions/mozmill@mozilla.com/resource/modules/frame.js -> file:///Users/adam/Desktop/mozilla/local_storage/tests/test_ls_base.js
lineNumber: 54
columnNumber: 0
location: JS frame :: file:///private/var/folders/YO/YOAvf2hSGt0+VnBIAKuImE+++TM/-Tmp-/tmpZZ1QY6.mozrunner/extensions/mozmill@mozilla.com/resource/modules/frame.js -> file:///Users/adam/Desktop/mozilla/local_storage/tests/test_ls_base.js :: anonymous :: line 54
inner: null
data: null
initialize: function initialize() { [native code] }

Comment 2

8 years ago
Moving to Core/Dom:Extensions which is the proper component.
Component: General → DOM: Mozilla Extensions
Product: Firefox → Core
QA Contact: general → general
Version: 3.5 Branch → Trunk
Attachment #380785 - Attachment mime type: text/x-c → text/plain
The problem here is the context in which the test gets executed. Somehow you don't access the localStorage object of the browser window? Executing the following Javascript code in the location bar of a browser window works fine.

javascript:{var storage = window.content.localStorage; storage.setItem("b", "true"); alert(window.content.localStorage.length)}

I think that it is a Mozmill problem.
Component: DOM: Mozilla Extensions → Mozmill
OS: Mac OS X → All
Product: Core → Testing
QA Contact: general → mozmill
Hardware: x86 → All

Comment 4

8 years ago
I'm trying to update Forecastfox to use localStorage as it's data storage mechanism.  I see this same error when running unit tests.  Even when I change the code to use window.content instead of just window.
Richard, which window are you using? A window from Forecastfox or a browser window? Would be nice to have a small extension which demonstrates this problem so we can figure out if it is really a general issue and not only affects Mozmill. How does your error looks like in detail?

Comment 6

8 years ago
Created attachment 398996 [details]
Forecastfox Test Build

This is the test build I'm working off.  I'm using a proxy file to point to the directory and load the file.  The file that is accessing localStorage is data-store.js.  I'm running the unit test by loading the url chrome://forecastfox/content/tests/data-store.html in the browser window.

Comment 7

8 years ago
Here is the latest error I'm getting on Firefox 3.5.3:

Error: uncaught exception: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIDOMStorageWindow.localStorage]"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: chrome://forecastfox/content/data-store.js :: DataStore_clear :: line 90"  data: no]
Restoring product/component since it also affects other extensions. Vladimir, can you help? Why is the localStorage object not available for extensions?
Component: Mozmill → DOM: Mozilla Extensions
Product: Testing → Core
QA Contact: mozmill → general
Not sure -- it might be expecting a document URI and not liking chrome URIs.  You want sdwilsh though, not me...
(In reply to comment #9)
> Not sure -- it might be expecting a document URI and not liking chrome URIs. 
> You want sdwilsh though, not me...
no no, you want honza!

(In reply to comment #8)
> Restoring product/component since it also affects other extensions. Vladimir,
> can you help? Why is the localStorage object not available for extensions?
As I understand it, it is for security reasons.  You can work around it by doing something similar to this test:
http://mxr.mozilla.org/mozilla-central/source/dom/tests/mochitest/localstorage/test_localStorageFromChrome.xhtml

Comment 11

8 years ago
Using the example in comment #10 I am able to call getItem, setItem on the storage object, but trying to access: removeItem, length, and clear results in the error below.

Exception... "Component is not available"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: chrome://forecastfox/content/datastore.js :: DataStore_all :: line 151"  data: no]

Another thing to note, is if I do (storage instanceof Components.interfaces.nsIDOMStorage) it returns false.

Comment 12

8 years ago
Am I right that this bug basically means "can't access localStorage from chrome:// documents"? Adjusting summary accordingly.

I don't see what it has to do with security, since globalStorage works just fine (after the fix in bug 371127).
Summary: Error trying to access localStorage length property from chrome → Can't access localStorage from chrome:// (exception: NS_ERROR_NOT_AVAILABLE - [nsIDOMStorageWindow.localStorage])
(Assignee)

Updated

8 years ago
Assignee: nobody → honzab.moz
(Assignee)

Updated

8 years ago
Flags: blocking1.9.2?
Not blocking 1.9.2 on this per discussion with Honza.
Flags: blocking1.9.2? → blocking1.9.2-

Comment 14

7 years ago
Wanted to use localStorage for the next version of ScribeFire; +1 for getting this fixed.
Wasn't there some temporary hack for this. Like using resource: urls or something.
Anyway, this should be fixed.
blocking2.0: --- → ?
Not holding the release for this.
blocking2.0: ? → -
status2.0: --- → wanted

Comment 17

7 years ago
The same problem in last Firefox 3.6.6

Comment 18

7 years ago
Hey guys
it's the same in 3.6.9
When this (if ever) gonna be fixed?
It really puts a stop to my development work..
Using mozStorage indeed does seem to be overkill when you just want to store key/values, although using the mochitest provided seems reasonable enough. Any plans for this in the 2.0 timeframe?
(In reply to comment #19)
> Using mozStorage indeed does seem to be overkill when you just want to store
> key/values, although using the mochitest provided seems reasonable enough. Any
> plans for this in the 2.0 timeframe?
This isn't blocking 2.0, but we'd probably take a patch if someone came around with one.

However, you probably don't want to use localStorage anyway since it's implemented by doing synchronous I/O on the main thread.  This can provide a degraded user experience for your add-on for some of your users.

Comment 21

6 years ago
Is this somehow related to Bug 509241, because from my extension I'm having errors sometimes accessing content.localStorage.length which I think are timing related errors. On our fast test machines we have no problems, but end-users keep reporting the error mentioned in bug 509241. Is this because of the synchronous I/O on the main thread?
(Assignee)

Comment 22

6 years ago
(In reply to comment #21)
> Is this somehow related to Bug 509241, because from my extension I'm having
> errors sometimes accessing content.localStorage.length which I think are
> timing related errors. On our fast test machines we have no problems, but
> end-users keep reporting the error mentioned in bug 509241. Is this because
> of the synchronous I/O on the main thread?

I don't understand fully what the problem is.

If you access localStorage.key(localStorage.length) result should be null or throw (the letter is a reported Firefox bug).

Do you expect there be an existing key under localStorage.length index?

What you reported might be more related to bug 662511.
I think we should deny access to local/session/globalStorage to all chrome:// URIs once we have IndexedDB in chrome up and working.  The synchronous storage APIs are bad for browser responsiveness, and if the footguns are there they will get used.

Comment 24

5 years ago
The main problem with chrome not having access to local (and session) storage is not lack of a way to store data, but lack of a way to store the data that a web page has stored.  There is currently no way to view multi-megabytes of data stored by web pages.  One day the wrong sort of publicity will come out about "secret super-cookies" and Firefox's reputation for security and privacy will take a dent.

Comment 25

5 years ago
The main problem with chrome not having access to local (and session) storage is not lack of a way to store data, but lack of a way to see the data that a web page has stored.  There is currently no way to view multi-megabytes of data stored by web pages.  One day the wrong sort of publicity will come out about "secret super-cookies" and Firefox's reputation for security and privacy will take a dent.

Comment 26

5 years ago
This kind of publicity about "secret super-cookies" is already out, and it focuses more on Flash storage. Localstorage is emptied upon clearing cookies.

Comment 27

5 years ago
Sorry for the double post earlier.

Exactly my point.  The bad publicity so far has been about Flash cookies.  Nobody has really picked up on DOM Storage, but sooner or later it will come to pass, and when somebody asks how much DOM Storage their browser is using the answer will be a big fat dunno.  People who get excited about these things will get excited.  Firebug and others have made heroic efforts to be able to display DOM storage keys for a page and it simply can't be done in all cases.  Despite the workaround methods for getting sessionStorage and localStorage, in some cases, keys are simply not visible to chrome (bug 442048, bug 709238, etc.).  Being able to delete it doesn't really cut the mustard if people can't even tell it is there.  How can anyone even know it has been deleted?

Comment 28

5 years ago
So you're saying because Firefox is unable to access localStorage in some cases (because of a bug) localStorage should be disabled because of bad publicity?

Nobody will pick up on localStorage as a privacy issue because all items are removed upon clearing history/cookies. Flash cookies however are not cleared hence the super-secret-cookie issue.

I think the mentioned bugs should be fixed so the usage of localStorage is like the way it should. If people really want to see their localStorage data they can download Firebug or some Firefox developer should include it in the Privacy tab to remove individual localStorage keys (and include the option to view the data the same way as cookies).

Comment 29

5 years ago
(In reply to Paul van Eijden from comment #28)
> So you're saying because Firefox is unable to access localStorage in some
> cases (because of a bug) localStorage should be disabled because of bad
> publicity?

Not at all. localStorage needs to stay.  It is an established and useful part of the standard, even if not widely used yet.  Just fix the bugs, of which there are several.

Do you know for sure that all storage is cleared when cookies are cleared?  Given that you can't see localStorage, it is difficult to be sure it is gone.  Did you know that sessionStorage is certainly not emptied when history is cleared?  Just something to think about for those people who don't think there is any issue here.
(Assignee)

Comment 30

5 years ago
I think this bug is invalidated with bug 495337.
(Assignee)

Updated

5 years ago
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 495337
Component: DOM: Mozilla Extensions → DOM
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.