Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 321ad9fa98b491aa3ef1cf319e22a5242259cc5e
https://github.com/WebKit/WebKit/commit/321ad9fa98b491aa3ef1cf319e22a5242259cc5e
Author: Chris Dumez <[email protected]>
Date: 2026-06-09 (Tue, 09 Jun 2026)
Changed paths:
M Source/WebCore/workers/service/context/ServiceWorkerInspectorProxy.cpp
M Source/WebKit/WebProcess/Storage/WebSWContextManagerConnection.cpp
M Source/WebKit/WebProcess/Storage/WebSWContextManagerConnection.h
Log Message:
-----------
WebSWContextManagerConnection inspector handlers call main-thread-only API
from a background WorkQueue
https://bugs.webkit.org/show_bug.cgi?id=316629
Reviewed by BJ Burg, Qianlang Chen, and Youenn Fablet.
WebSWContextManagerConnection is an IPC::WorkQueueMessageReceiver, so every
message declared in WebSWContextManagerConnection.messages.in is dispatched
on m_queue rather than the main run loop. Every other handler in the file
correctly pairs assertIsCurrent(m_queue.get()) with a callOnMainRunLoop hop
when it needs to touch main-thread state. The three inspector handlers
(connectToInspector, disconnectFromInspector, dispatchMessageFromInspector)
forgot to do this and called SWContextManager::serviceWorkerThreadProxy()
— which ASSERT(isMainThread()) — directly from the queue, then dereferenced
the returned proxy to call into ServiceWorkerInspectorProxy, whose state
(m_channel raw pointer, SWContextManager::m_connection access in
setAsInspected) is unsynchronized main-thread state. In debug this fires
the assertion; in release it races the main thread, including a torn-pointer
race against ServiceWorkerInspectorProxy::sendMessageFromWorkerToFrontend
which reads m_channel from the main run loop.
Hop the main-thread-bound calls via callOnMainRunLoop to match the rest of
the file. The m_channels map is only touched from these three handlers, and
the channels it owns are used exclusively on the main run loop by
ServiceWorkerInspectorProxy. WebSWContextManagerConnection is itself
destroyed on the main run loop (DestructionThread::MainRunLoop), so any
channel still in m_channels at destruction time is torn down there. Rather
than confine the map to m_queue and destroy leftover channels on a different
thread than the one that normally removes them, confine the map to the main
run loop: create the channel, add it to / take it from m_channels, and call
into ServiceWorkerInspectorProxy all inside the callOnMainRunLoop hop, and
annotate m_channels with WTF_GUARDED_BY_CAPABILITY(mainRunLoop) so the
compiler enforces that single-thread invariant going forward. This makes
create/add/remove/destroy of every channel happen consistently on the main
run loop. isolatedCopy the inspector message string for the cross-thread
move in dispatchMessageFromInspector. Keep a null-channel guard in
disconnectFromInspector so that an unbalanced disconnect (channel never
inserted, or a duplicate disconnect) no longer dereferences a null RefPtr.
Also add ASSERT(isMainThread()) to the non-trivial ServiceWorkerInspectorProxy
methods so any future regression is caught at the source rather than
manifesting as a race.
* Source/WebCore/workers/service/context/ServiceWorkerInspectorProxy.cpp:
(WebCore::ServiceWorkerInspectorProxy::serviceWorkerTerminated):
(WebCore::ServiceWorkerInspectorProxy::connectToWorker):
(WebCore::ServiceWorkerInspectorProxy::disconnectFromWorker):
(WebCore::ServiceWorkerInspectorProxy::sendMessageToWorker):
(WebCore::ServiceWorkerInspectorProxy::sendMessageFromWorkerToFrontend):
* Source/WebKit/WebProcess/Storage/WebSWContextManagerConnection.cpp:
(WebKit::WebSWContextManagerConnection::connectToInspector):
(WebKit::WebSWContextManagerConnection::disconnectFromInspector):
(WebKit::WebSWContextManagerConnection::dispatchMessageFromInspector):
* Source/WebKit/WebProcess/Storage/WebSWContextManagerConnection.h:
Canonical link: https://commits.webkit.org/314878@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
