User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.14 Safari/534.24 Build Identifier: 4.0 (This all the Help | About menu says) If I have a local webpage (running from file:///), any attempt to create an indexedDB will throw this exception: uncaught exception: [Exception... "The operation failed for reasons unrelated to the database itself and not covered by any other error code." code: "1" nsresult: "0x80660001 (NS_ERROR_DOM_INDEXEDDB_UNKNOWN_ERR)"] There error happens as soon as you attempt to open the db: indexedDB.open("filler"); Webkit/Chromium allows users to have indexedDBs on local webpages. The filename they use is "__0.indexeddb " If you're not planning on supporting this, having a more informative error message would be very helpful. Reproducible: Always Steps to Reproduce: 1. Attempt to open an indexedDB on a locally hosted webpage (from file:///) 2. 3. Actual Results: Exception thrown: uncaught exception: [Exception... "The operation failed for reasons unrelated to the database itself and not covered by any other error code." code: "1" nsresult: "0x80660001 (NS_ERROR_DOM_INDEXEDDB_UNKNOWN_ERR)"] Expected Results: Successful creation of indexedDB

When this happens, we show WARNING: IndexedDB databases not allowed for this principal! since we hit rv = nsContentUtils::GetASCIIOrigin(principal, origin); .. if (origin.EqualsLiteral("null")) { in IDBFactory::Open. That is, file:/// URLs have null as their ASCII origin, and for some reason we don't allow that. Does anyone know why?

The problem is that anything you save in the database could be read by any other page saved by the user on his/her hard drive. The security model for file: is really complicated. Until we figure out some sort of comprehensive solution I really don't know what we can do here.

I see, thanks for the explanation. Meanwhile it isn't hard to work around this, with say python -m SimpleHTTPServer 8000 which runs a webserver in a specific directory (reachable at localhost:8000, so it passes the ascii origin test...).

we could add some environment variable/pref/command line switch to control this for web devs while they're testing, perhaps.

Just ran into this as well and it's pretty annoying to need a web server running just to test out some code. If the decision is that local files can't interact with indexedDB for security reasons, I can understand that. What I can't understand is why this error doesn't cause the onerror callback to be called so that normal error handling can proceed. Making that change would be very helpful for compatibility. As a side note: with localStorage on local files, it seems that Firefox allows its usage during the page lifecycle and then deletes it when the page is unloaded. Would that not also work for indexedDB?

I hit the issue with localStorage either not being used or being wiped on page reload, is it a consequence of the same security policy as for indexedDB or is it another bug? It works fine in Opera and Chrome.

Chris, this isn't really a spec issue... This is more about finding a way to properly prevent data created by one file:// page from being read in a different file:// page.

Yes. The way our security policy for file:// works, each file is a different origin from each other file. I've had the idea to enable defining local "sites" in which we could allow things like indexedDB and more sane same origin policies. I filed bug 701774 on that.

Could you add an advice on MDN?

Hi, I actually created an account to weigh in on this. First off, <suckup>thanks for an awesome product I use ever day</suckup> I ran into this issue when I was working on an offline app. From the stuff I've read around the net about indexed_db, several people mentioned how it opened up more possibilities for offline dev. I agree, and hope that there are plans to fix this. I'd rather see this than use something like LocalStorage.

(In reply to Alon Zakai (:azakai) from comment #1) > When this happens, we show > > WARNING: IndexedDB databases not allowed for this principal! Firefox 11.0 does not show that message but a rather useless "The operation failed for reasons unrelated to the database itself and not covered by any other error code." As a result indexedDB is useless for local browserapps, games etc.

I, also, created an account just to comment on this. I understand the reasoning behind the security policy on this, but in my personal use, the benefits to using indexedDB in offline apps far outweigh any potential risks behind file:// pages sharing an origin. Something like a few config settings to adjust origin scope (by depth of the path, maybe?) would be very helpful. In the meantime, I either have to host a webserver just for local testing and offline apps, or switch to chrome, which doesn't have this issue.

This is on khuey's list. Our short term plan is to treat every file as its own security context (so any file:// can use indexedDB but no two file:// may share databases).

Firefox 13 still not show an explicit message but : "The operation failed for reasons unrelated to the database itself and not covered by any other error code." An advice on MDN may be usefull ;)

Still getting this bug in Firefox 14. Is this thread the place to follow whether a per-page solution is progressing?

Also signed up just for this, please "fix" this.

Actually, we recently moved sone vode around that might have affected this bug. Could soneone verify that this still doesn't work in recent nightlies?

It seems to be working on Nightly. Marking as fixed.

As of today indexedDB.open(name, version) silently fails (no trigger of the onerror() function) when asked from a local file (i.e. served from the file:// protocol). This has been tested both on Linux and Windows with: * Firefox Desktop release, * Aurora * Nightly Could others confirm the same diagnostic please? And if so, could this bug be reopened? Or should I open a new ticket? Please tell me! Thank you

Marc-Aurèle, can you provide a testcase that shows the problem you are seeing on Nightly?

(In reply to Alon Zakai (:azakai) from comment #20) > Marc-Aurèle, can you provide a testcase that shows the problem you are > seeing on Nightly? I'm so very sorry: when cleaning the files I used to assess the problem to add them to this ticket, everything worked just fine. I first encounter the problem while developing an Open Web App which uses IndexedDB both online and offline. And there is problem in this case. I thought it could run down to be a problem of opening an IndexedDB locally, but it's not the exact same problem it seems. Sorry for the disturbance.