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.
This does not affect the Chromium port, only DumpRenderTree.
(In reply to comment #1) > This does not affect the Chromium port, only DumpRenderTree. Why? What about other ports?
(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.