[DumpRenderTree] IndexedDB: Each page group/worker has a distinct IDBFactoryBackend

• Component: WebKit Misc.
• Status: NEW ---

[Joshua Bell]

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.

[Joshua Bell]

This does not affect the Chromium port, only DumpRenderTree.

[Sergio Villar Senin]

(In reply to comment #1)
> This does not affect the Chromium port, only DumpRenderTree.

Why? What about other ports?

[Joshua Bell]

(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.