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)

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] }

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

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.

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?

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.

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?

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

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.

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

Not blocking 1.9.2 on this per discussion with Honza.

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.

Not holding the release for this.

The same problem in last Firefox 3.6.6

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.

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?

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

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.

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.

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

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?

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

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

I think this bug is invalidated with bug 495337.