IndexedDB Connection Recovery After Network Process Crash

3c147a6

Source/WebCore/Modules/indexeddb/IDBFactory.cpp

Source/WebKit/WebProcess/WebProcess.cpp

IndexedDB in WebKit splits across the WebContent and Network processes. The WebContent process holds an IDBConnectionProxy — a handle into the Network process's IDB implementation — cached at multiple levels: Page, Document, WorkerGlobalScope, and IDBFactory. When the Network process crashes, those cached proxies become dangling handles. Previously, WebKit required a page reload to clear them.

This commit threads a "clear and lazily recreate" signal through the entire object graph. On Network process crash, each Document's cached proxy is nulled out. On next indexedDB.open() call, IDBFactory::ensureConnectionProxy() detects the stale proxy (by comparing its raw pointer against the Document's current proxy) and swaps in the new one. Worker proxy refresh is deferred until the Network process is relaunched for another reason, to avoid unnecessary process spawning.

NetworkProcess crash
        │
        ├──► Page::clearIDBConnectionOnAllDocuments()
        │         └──► Document::clearIDBConnectionProxy()   ← nulls m_idbConnectionProxy
        └──► WebProcess::m_needsIDBConnectionRefreshForWorkers = true

Next indexedDB.open() (document)
        └──► IDBFactory::ensureConnectionProxy()  ← lazily recreates from new Page connection

Network process relaunches (any reason)
        └──► drains m_needsIDBConnectionRefreshForWorkers
                  └──► WorkerGlobalScope::replaceIDBConnectionProxyOnAllWorkers()

Significance

This eliminates the user-facing "refresh the page" requirement for IndexedDB after a Network process crash, improving web app resilience. The change touches the proxy lifecycle at every caching layer — Page, Document, Worker, IDBFactory — requiring correct ordering and lifetime discipline at each.

Audit directions