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

Status: RESOLVED DUPLICATE of bug 495337

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

Description

[Adam Christian]

Attachment: 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)

Comment 1

[Adam Christian]

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/[e-mail]/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/[e-mail]/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

[cmtalbert]

Moving to Core/Dom:Extensions which is the proper component.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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.

Comment 4

[Richard Klein]

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.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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

[Richard Klein]

Attachment: 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

[Richard Klein]

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]

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Restoring product/component since it also affects other extensions. Vladimir, can you help? Why is the localStorage object not available for extensions?

Comment 9

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Not sure -- it might be expecting a document URI and not liking chrome URIs.  You want sdwilsh though, not me...

Comment 10

[Shawn Wilsher :sdwilsh]

(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

[Richard Klein]

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

[Nickolay_Ponomarev]

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).

Comment 13

[Johnny Stenback (:jst)]

Not blocking 1.9.2 on this per discussion with Honza.

Comment 14

[Christopher Finke]

Wanted to use localStorage for the next version of ScribeFire; +1 for getting this fixed.

Comment 15

[Olli Pettay [:smaug][[e-mail]]]

Wasn't there some temporary hack for this. Like using resource: urls or something.
Anyway, this should be fixed.

Comment 16

[Johnny Stenback (:jst)]

Not holding the release for this.

Comment 17

[Dmytrii Shchadei]

The same problem in last Firefox 3.6.6

Comment 18

[Andrei]

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..

Comment 19

[Jonathan Protzenko [:protz]]

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?

Comment 20

[Shawn Wilsher :sdwilsh]

(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

[Paul van Eijden]

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?

Comment 22

[Honza Bambas (:mayhemer)]

(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.

Comment 23

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

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

[Ian Nartowicz]

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

[Ian Nartowicz]

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

[Paul van Eijden]

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

[Ian Nartowicz]

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

[Paul van Eijden]

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

[Ian Nartowicz]

(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.

Comment 30

[Honza Bambas (:mayhemer)]

I think this bug is invalidated with bug 495337.