Closed Bug 774250 Opened 10 years ago Closed 10 years ago

IndexedDB: encoding error writing quota in sqlite file


(Core :: Storage: IndexedDB, defect)

Windows 7
Not set



blocking-basecamp -
Tracking Status
firefox15 --- wontfix
firefox16 --- fixed
firefox17 --- verified
firefox18 --- verified
firefox-esr10 --- wontfix


(Reporter: eric.abouaf, Assigned: khuey)




(1 file)

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20100101 Firefox/13.0.1
Build ID: 20120614114901

Steps to reproduce:

 * create a Windows user containing accents in its name ( ex: "Propriétaire" (aka "Owner") is the default user name in French, so its really frequent ), and launch Firefox with this user.

 * Re-open an existing indexedDB database

Actual results:

Trying to reopen the database will raise an exception with errorCode 1 (unknown error)

Same issue than in

Expected results:

The database should open correctly.

Details :

The error comes from the "UpdateQuotaInformationForFile" function in

    int rc = ::sqlite3_quota_file(PromiseFlatCString(path).get());

Here, the result code returned by sqlite is an error (unable to open the file), so I first thought that the issue was from sqlite.

I built a simple test case to test the sqlite code, and I could reproduce the bug :

   int rc = ::sqlite3_quota_file("C:\Documents and Settings\Proprietaire\...path to the indexedb sqlite file..."); // SUCCESS

   int rc = ::sqlite3_quota_file("C:\Documents and Settings\Propriétaire\...path to the indexedb sqlite file..."); // FAILS IF NOT IN UTF 8, SUCCESS IF IN UTF-8

So, sqlite expects utf8 filenames in the sqlite3_quota_file and sqlite3_quota_set calls (lines 905 and 923)

So I don't know which encoding is PromiseFlatCString(path).get() in, but we should convert it to UTF-8 before making the sqlite code.

This makes no difference unless you have accents in the path of the firefox Profile, but fails for most French users :(
Blocks: 766489
OS: Windows XP → Windows 7
See Also: → 766489
Jan or Kyle, can you poke around a little here before I get back from the east coast? Would be good to know what's going wrong here.
Severity: normal → major
Component: Untriaged → DOM: IndexedDB
Product: Firefox → Core
Version: 13 Branch → Trunk
I think we need to change GetNativePath() to GetPath() and
 then convert the path to UTF8
Assignee: nobody → Jan.Varga
Ever confirmed: true
Any update ?

It's a very common bug on computers of non-English-speaking people.

IndexedDB should not ship unprefixed before it has been fixed.
quite annoying bug for us, a lot of our users have to create another windows username without any accent. Is there another workaround ? Can we do something to help ?
blocking-basecamp: --- → ?
Jonas doesn't think this is critical (or affecting?) B2G so blocking- for Basecamp.
blocking-basecamp: ? → -
With that fix the entire IndexedDB test suite that we have passes when run from a profile directory on a user named 'Propriétaire'.
Though, it turns out our test suite can never hit the scenario in this bug, because it requires restarting the browser, so that's not a very useful test.
(In reply to comment #9)
> Backed out because of Linux opt Moth orange:
> Example log:

And, it seems like the orange has been intermittent?!  Kyle, please reland if you think that's appropriate, I'm not sure what needs to be done here :/
It doesn't look to me like it was the least bit intermittent, it looks like it failed on every single Linux32 run which started between 14:30 and 15:30 (or, ran that test between some times after those).

Relanded in
Comment on attachment 663026 [details] [diff] [review]
As landed

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Was in the original indexedDB implementation (in Firefox 4)
User impact if declined: IndexedDB will not work properly on Windows machines where the username has non-ASCII characters.  At the very least, the default username in the French locale hits this bug.
Testing completed (on m-c, etc.): Landed on m-c.
Risk to taking this patch (and alternatives if risky): Very low risk patch.  We just get the unicode path in two places where we used to get the path in the system codepage.
String or UUID changes made by this patch: None.
Attachment #663026 - Flags: approval-mozilla-beta?
Attachment #663026 - Flags: approval-mozilla-aurora?
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
Comment on attachment 663026 [details] [diff] [review]
As landed

[Triage Comment]
Approving for Aurora 17 due to the risk evaluation, and Beta 16 due to the unprefixing in bug 726378.
Attachment #663026 - Flags: approval-mozilla-beta?
Attachment #663026 - Flags: approval-mozilla-beta+
Attachment #663026 - Flags: approval-mozilla-aurora?
Attachment #663026 - Flags: approval-mozilla-aurora+
Keywords: verifyme
Duplicate of this bug: 766489
While trying to reproduce this:
1. Go to
2. Load the html example in FF
3. Press the button

Actual results:
nothing happens

Not the same result in Chrome.
I've tested this on Nightly 2012-09-04 before the fix:
1. Create user "Propriétaire"
2. Open in FF
3. Add some random customers
4. Set FF to remember tabs and windows from last time
5. Restart FF
6. Click again to add a customer
Actual results:
The DB won't open. "Unknown error" in error console

Tested again on FF 17b6. The DB is not automatically opened after restart, but the list shows up after clicking to add a new customer. I'm considering this verified fixed.
Verified fixed on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0b1
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.