Last Comment Bug 643318 - IndexedDB: Webpages running locally cannot create indexedDB
: IndexedDB: Webpages running locally cannot create indexedDB
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: DOM: IndexedDB (show other bugs)
: Trunk
: All All
: -- normal with 5 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
file:///*
Depends on: 701774
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-20 13:39 PDT by jonnew
Modified: 2013-01-18 07:21 PST (History)
23 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description jonnew 2011-03-20 13:39:12 PDT
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
Comment 1 Alon Zakai (:azakai) 2011-04-07 11:29:19 PDT
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?
Comment 2 Jonas Sicking (:sicking) 2011-04-07 12:51:26 PDT
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.
Comment 3 Alon Zakai (:azakai) 2011-04-07 12:55:50 PDT
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...).
Comment 4 Ben Turner (not reading bugmail, use the needinfo flag!) 2011-04-07 13:00:52 PDT
we could add some environment variable/pref/command line switch to control this for web devs while they're testing, perhaps.
Comment 5 Nicholas C. Zakas 2011-05-25 13:54:03 PDT
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?
Comment 6 heraldo 2011-08-25 11:57:06 PDT
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.
Comment 7 Ben Turner (not reading bugmail, use the needinfo flag!) 2011-11-11 08:35:00 PST
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.
Comment 8 Jonas Sicking (:sicking) 2011-11-11 10:29:13 PST
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.
Comment 9 Marco Castelluccio [:marco] 2011-12-23 09:00:30 PST
Could you add an advice on MDN?
Comment 10 ascavone 2012-04-12 09:13:55 PDT
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.
Comment 11 S. Burmeister 2012-04-28 05:31:13 PDT
(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.
Comment 12 rorschach.prime 2012-06-14 11:23:36 PDT
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.
Comment 13 Ben Turner (not reading bugmail, use the needinfo flag!) 2012-06-14 12:41:19 PDT
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).
Comment 14 julien.meilleroux 2012-06-27 08:56:47 PDT
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 ;)
Comment 15 Patrick Hall 2012-07-15 16:31:40 PDT
Still getting this bug in Firefox 14. Is this thread the place to follow whether a  per-page solution is progressing?
Comment 16 Terrance A. Snyder 2012-10-08 15:50:39 PDT
Also signed up just for this, please "fix" this.
Comment 17 Jonas Sicking (:sicking) 2012-10-08 15:56:26 PDT
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?
Comment 18 Mounir Lamouri (:mounir) 2012-10-08 16:28:13 PDT
It seems to be working on Nightly. Marking as fixed.
Comment 19 Marc-Aurèle DARCHE 2013-01-14 08:20:26 PST
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
Comment 20 Alon Zakai (:azakai) 2013-01-17 10:03:07 PST
Marc-Aurèle, can you provide a testcase that shows the problem you are seeing on Nightly?
Comment 21 Marc-Aurèle DARCHE 2013-01-18 07:21:20 PST
(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.

Note You need to log in before you can comment on or make changes to this bug.