82776 2012-03-30 13:43:40 -0700 [DumpRenderTree] IndexedDB: Each page group/worker has a distinct IDBFactoryBackend 2013-04-11 16:18:34 -0700 1 1 1 Unclassified WebKit WebKit Misc. 528+ (Nightly build) Unspecified Unspecified NEW P2 Normal --- 107194 82678 1 jsbell michael abarth charles.wei dgrogan svillar oldest_to_newest 592461 0 jsbell 2012-03-30 13:43:40 -0700 The PageGroupIndexedDatabase and WorkerContextIndexedDatabase classes contain IDBFactoryBackendInterface members which are initialized lazily. The IndexedDB implementation assumes there is a single IDBFactoryBackendImpl instance for the entire browser, since it controls access to the backing store, maintains open database connections, and schedules transactions. The result is that a page and worker, or two workers, that attempt to open connections to the same database end up talking to completely distinct database instances. 592462 1 jsbell 2012-03-30 13:43:59 -0700 This does not affect the Chromium port, only DumpRenderTree. 832974 2 svillar 2013-02-14 04:57:18 -0800 (In reply to comment #1) > This does not affect the Chromium port, only DumpRenderTree. Why? What about other ports? 833162 3 jsbell 2013-02-14 09:43:01 -0800 (In reply to comment #2) > (In reply to comment #1) > > This does not affect the Chromium port, only DumpRenderTree. > > Why? In full-blown Chromium, the back-end objects run in a different process; all front-end objects talk through proxies which implement IPC to the same back-end. This is true in Chromium's chrome browser and content_shell. The Chromium port of test_shell (used for DumpRenderTree) is single-process, and runs into the issue in the bug Description. > What about other ports? Other ports did not implement IndexedDB at the time I wrote that. I don't know the state of the other ports at the moment, but they would likely run into this issue unless they implement a similar mechanism for separating front- and back-ends.