New issue
Advanced search Search tips
Starred by 11 users

Issue metadata

Status: Fixed
Closed: Aug 2012
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug

  • Only users with EditIssue permission may comment.

Sign in to add a comment

Issue 143680: indexedDB is broken in Canary on Windows

Reported by, Aug 20 2012

Issue description

Chrome Version       : 23.0.1239.0
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: OK
  Firefox 4.x: OK
     IE 7/8/9: FAIL, FAIL, OK

What steps will reproduce the problem?
1. Go to and select Chrome
2. On the top right corner click "Load Pre-requisites"
3. Click "Run"

What is the expected result?

See screenshot OK.jpg.

What happens instead?

See screenshot FAIL.jpg.

Please provide any additional information below. Attach a screenshot if

It works on release branch of Chrome 

UserAgentString: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.6 (KHTML, like Gecko) Chrome/23.0.1239.0 Safari/537.6
123 KB View Download

Comment 1 by, Aug 21 2012

Labels: Feature-IndexedDB

Comment 2 by, Aug 21 2012

Thanks for the report. Could you try with a new profile[1] and let us know if you see the same problem? Keep the existing profile though, it might be helpful for us to inspect the IndexedDB directory if we discover that there is a bug in chrome.

Starting on 8/18 or 8/19, chrome canary started supporting the upgradeneeded versioning mechanism and a new code path is exercised when opening databases.

1. On linux you can pass --user-data-dir=/tmp/some_temp_dir to temporarily use a new profile.  That should work on windows also.

Comment 3 by, Aug 21 2012

Sounds like there's a step missing from the repro.

Is there a missing step between 1 and 2, "select open Database" on the left?

If so, it works for me in a tip-of-tree build. However, I note that in the screenshots you have:

var request ="BookShop1", 1);

whereas in the live sample on the site you have;

var request ="BookShop1");

As dgrogan@ noted, Chrome Canary just exposed the upgradeneeded mechanism (so open takes a version argument). Can you make sure the live version of the test matches the repro steps for error you're seeing, and/or attach a stand-alone sample?

Comment 4 by, Aug 21 2012 Same results on a new profile. Chrome parameter worked on Windows. Profile attached (

I do use version number parameter. Screenshot attached (FAIL.JPG) — yes, sorry for that. I do pass version number argument to the open method.

That code successfully runs on FF 14.0.1
3.6 MB Download
86.8 KB View Download

Comment 5 by, Aug 21 2012 I attached js piece against which I tested "open" method.
1.5 KB View Download

Comment 6 by, Aug 22 2012

Works for me with these repro steps:

1. Go to
2. Click "Google Chrome ... canary"
3. Close the pop-up.
4. Copy/paste the contents of the "test.js" linked to above into the editor area
5. Click "Run"


[14:03:26] Trying to open database with version 1
[14:03:26] Database upgrade needed
[14:03:26] Database Opened  [Object]   [Object] 

Closed tab, ran the steps again, output:

[14:04:35] Trying to open database with version 1
[14:04:36] Database Opened  [Object]   [Object]

Comment 7 by, Aug 22 2012

That's with a fresh Chromium build from the tip of the tree on Linux, BTW.

Comment 8 by, Aug 25 2012

If you pass in a version parameter to open(), it breaks.  No event handlers are called, the database is corrupted (dev tools throw an error if you try to view it), and the only way to remove it is via deleting the subdirectory in <profile>\IndexedDB for the site.

22.0.1243.2 Dev Windows 8 Release Preview x64

Comment 9 by, Aug 25 2012

The examples in the linked site seem to work for me, including the ones dealing with versions.  I am coding a Chrome App.

Comment 10 Deleted

Comment 11 by, Aug 26 2012

I can confirm that version argument to the open method still breaks indexedDB on 23.0.1245.0 on Windows 7 x64.

Comment 12 by, Aug 26 2012

megazzt and bogdan,

When I start chrome with a new temporary profile and do the steps jsbell@ listed in comment 6, I get

[15:48:45] Trying to open database with version 1
[15:48:46] Database upgrade needed
[15:48:46] Database Opened  [Object]   [Object]

Will you repeat exactly those steps? What do you get?  If it's something different than what I get, could you 1) describe or give screenshots and 2) Upload or email your IndexedDB directory?

megazzt, if the above steps work for you, could you give us steps to reproduce the problem you are seeing? Uploading a sample javascript file like bogdan did would be excellent.

Comment 13 by, Aug 26 2012

I do exactly those steps. Just did that once again. Current Canary build is 23.0.1245.0. See attached screenshot. It's a pure profile. I used --user-data-dir flag. You may also find attached profile somewhere in the comments.
114 KB View Download

Comment 14 by, Aug 26 2012

As I already stated, that site works for me.

It's only calling .open() from my code with a second version parameter that is broken (everything works if I omit that parameter and use the outdated spec for managing versions), as bogdan said.

Comment 15 by, Aug 27 2012

megazzt, yes, you already said that the examples in that site work for you.  You have still not yet said if you followed the reproduction steps from comment 6 in a fresh profile.  Have you?

bogdan, could you try running chrome in single-process mode.  In addition to the --user-data-dir flag, could you pass --single-process and let us know if you get different IndexedDB behavior?  Single process mode cycles in and out of stability so the browser might just crash on you sometime.  But hopefully you can get a test in.

Thanks, both of you, for your help with this bug.

Comment 16 by, Aug 27 2012

dgrogan, unfortunately, that flag causes canary to crash every time: browser starts, I see yellow bar at the top of the window that says I’m using unsupported flag and that stability and security are going to be compromised. Then it crashes.

Maybe megazzt will have a better luck with this flag.

Comment 17 by, Aug 27 2012

Fresh profile, examples still work.

Comment 18 by, Aug 27 2012

megazzt Hey mate, how about version number argument? If you pass this argument to the open method on a fresh Canary profile, what would you see?

dgrogan and jsb suggest that it might be related to chrome extensions or something like that on our canary builds.

To skip this assumption they suggest to start Canary with that flag (with an argument pointing to some empty temporary directory).

Comment 19 by, Aug 27 2012

I can repro my problem on a fresh profile with the devtools open on the NTP."test", 1) is all I need to do.  If I try to view the DB in dev tools it throws an error.

Comment 20 by, Aug 27 2012

The reason for the --user-data-dir suggestion was to see if the bug was in our migration code that preps an existing IDB for use with integer versions.  As bogdan can reproduce the problem in a profile that has no existing databases, we can rule out the migration code.

Comment 21 by, Aug 27 2012

Ah, sorry, dgrogan. I should have rid of my bad habit of building false assumptions long time ago %) How can I help more on this issue?

Comment 22 by, Aug 27 2012

So here are some experiments I've done with the latest canary...

All of this is done using the JS API on the console, while simply visiting Starting with a fresh profile, no indexeddb's present.

1) I try to open "xx", nothing happens (i.e. no callbacks are fired)
2) If I try to open a second database ("xy") also using "Example" as the version, it opens fine and both onupgradeneeded and onsuccess are fired
3) now if I got back and try to open the first one, it opens just fine
4) I use indexedDB.deleteDatabase("xy") to delete the 2nd one, and it succeeds just fine
5) I use indexedDB.deleteDatabase("xx"), but this time the database wont' delete.

I just went through this and realized - in some cases I am just writing on the console:

> indexedDB.deleteDatabase("xx")

From then on, that particular database seems to be in some strange state - it still shows up when I call indexedDB.webkitGetDatabaseNames(), and when I call deleteDatabase() on it, neither the success nor the error handler fires. 

I think there may be an issue when the browser is allowed to return to the event loop before any events are attached - I think indexedDB somehow thinks those operations are still in-flight. I was eventually able to get the database to go away by completely quitting chrome and restarting, then calling delete again.

Comment 23 by, Aug 27 2012

Labels: -Pri-2 -Area-Undefined Pri-1 Area-WebKit WebKit-Storage Mstone-23
After discussion with alecflett@, some of the above behavior could be due to non-deterministic GC behavior since the connection was never closed.

But I am able to repro the "just don't get events" in a Windows Canary build, just not my local Linux Debug build from tip of tree. Sample attached - should log SOME event from the open request, but it doesn't.
499 bytes View Download

Comment 24 by, Aug 27 2012

Status: Assigned
Agreed that some event should fire with broke.html.  Opening broke.html in mac canary results in upgradeneeded and then success, so we're looking at a windows-only issue.

broke.html passes a string as a version parameter, which we have no tests for.  Removing that parameter altogether should get events firing again, but I'll add tests for passing string version parameters and see what happens on the various platforms.

Comment 25 by, Aug 27 2012

I double checked canary since I have been testing on Dev... I can repro my problem in Canary.

My steps are:
- Open NTP
- Open Dev Tools
- Type, 1)
- Type
- Switch to resources tab and check out IndexedDB stuff.
- Open Dev Tools from inside Dev Tools (Ctrl+Shift+J).
- Observe an error is thrown when trying to view SOMESTRING db, but not SOMEOTHERSTRING db.

This error is not limited to NTP, but it is easiest to test from there.

Comment 26 by, Aug 27 2012

It just occurred to me that that may be a separate problem due to never handing the update event.  The error I am seeing may be just a Dev Tools bug then...

I would have to have a more verbose repro case I guess to see if my original problem is still happening.

Comment 27 by, Aug 27 2012

Windows Debug build from tip-of-tree shows a DCHECK failure running the broke.html test from comment #23.

[14040:20288:7704187:FATAL:indexed_db_callbacks.h(98)] Check failed: false. 
	base::debug::StackTrace::StackTrace [0x10075D61+33] (c:\src\chromium\src\base\debug\
	logging::LogMessage::~LogMessage [0x100CC71E+94] (c:\src\chromium\src\base\
	IndexedDBCallbacks<WebKit::WebIDBDatabase>::onUpgradeNeeded [0x0859C201+241] (c:\src\chromium\src\content\browser\in_process_webkit\indexed_db_callbacks.h:98)
	WebKit::IDBCallbacksProxy::onUpgradeNeeded [0x104B3BE9+265] (c:\src\chromium\src\third_party\webkit\source\webkit\chromium\src\idbcallbacksproxy.cpp:140)
	WebCore::IDBDatabaseBackendImpl::setIntVersionInternal [0x12295817+487] (c:\src\chromium\src\third_party\webkit\source\webcore\modules\indexeddb\idbdatabasebackendimpl.cpp:301)
	WebCore::CrossThreadTask4<WTF::PassRefPtr<WebCore::IDBDatabaseBackendImpl>,WTF::PassRefPtr<WebCore::IDBDatabaseBackendImpl>,__int64,__int64,WTF::PassRefPtr<WebCore::IDBCallbacks>,WTF::PassRefPtr<WebCore::IDBCallbacks>,WTF::PassRefPtr<WebCore::IDBTransacti [0x122A186E+190] (c:\src\chromium\src\third_party\webkit\source\webcore\dom\crossthreadtask.h:183)
	WebCore::IDBTransactionBackendImpl::taskTimerFired [0x11745D8C+524] (c:\src\chromium\src\third_party\webkit\source\webcore\modules\indexeddb\idbtransactionbackendimpl.cpp:266)

Comment 28 by, Aug 28 2012

Summary: indexedDB is broken in Canary on Windows

Comment 29 by, Aug 28 2012

I couldn't make this code work and compile in both windows and mac/linux, just one or the other. I'm going to de-templatize indexed_db_callbacks. The templates don't buy us much anyway since every type has a specialization except for Transaction.

With luck this will be in wednesday's canary but more likely thursday's or friday's.

Comment 30 by, Aug 30 2012

Project Member
The following revision refers to this bug:

r154111 | | 2012-08-30T10:14:21.789767Z

Changed paths:

Change some IndexedDBCallbacks<> specializations to derived classes

Specifically, removes IndexedDBCallbacks<WebIDB{Transaction, Database}> in
favor of IndexedDBCallbacks{Transaction, Database}.

Also runs some integer version layout tests as browser tests. This would have
exposed  bug 143680  earlier.

BUG= 143680 

Review URL:

Comment 31 by, Aug 30 2012

Status: Fixed
This is fixed in canary.

Comment 32 by, Oct 14 2012

Project Member
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.

Comment 33 by, Oct 17 2012

Labels: -Feature-IndexedDB WebKit-Storage-IndexedDB

Comment 34 by, Mar 10 2013

Project Member
Labels: -Area-WebKit -WebKit-Storage -Mstone-23 -WebKit-Storage-IndexedDB Cr-Content Cr-Content-Storage-IndexedDB Cr-Content-Storage M-23

Comment 35 by, Mar 14 2013

Project Member
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue

Comment 36 by, Apr 6 2013

Project Member
Labels: -Cr-Content Cr-Blink

Comment 37 by, Apr 6 2013

Project Member
Labels: -Cr-Content-Storage-IndexedDB Cr-Blink-Storage-IndexedDB

Comment 38 by, Apr 6 2013

Project Member
Labels: -Cr-Content-Storage Cr-Blink-Storage

Sign in to add a comment