NEW 82776
[DumpRenderTree] IndexedDB: Each page group/worker has a distinct IDBFactoryBackend 
https://bugs.webkit.org/show_bug.cgi?id=82776
Summary [DumpRenderTree] IndexedDB: Each page group/worker has a distinct IDBFactoryB...
Joshua Bell
Reported 2012-03-30 13:43:40 PDT
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.
Attachments
Add attachment proposed patch, testcase, etc.
Joshua Bell
Comment 1 2012-03-30 13:43:59 PDT
This does not affect the Chromium port, only DumpRenderTree.
Sergio Villar Senin
Comment 2 2013-02-14 04:57:18 PST
(In reply to comment #1) > This does not affect the Chromium port, only DumpRenderTree. Why? What about other ports?
Joshua Bell
Comment 3 2013-02-14 09:43:01 PST
(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.
Note You need to log in before you can comment on or make changes to this bug.