Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: cc7a6821b7cceb7cb9e2836a9dfc11a42691683a
https://github.com/WebKit/WebKit/commit/cc7a6821b7cceb7cb9e2836a9dfc11a42691683a
Author: Chris Dumez <[email protected]>
Date: 2026-08-18 (Tue, 18 Aug 2026)
Changed paths:
M LayoutTests/platform/mac-wk2/TestExpectations
M Source/WTF/wtf/PlatformHave.h
M Source/WebKit/NetworkProcess/NetworkResourceLoader.cpp
M Source/WebKit/NetworkProcess/NetworkResourceLoader.h
Log Message:
-----------
REGRESSION(318278@main?)[macOS]: ASSERTION FAILED: !m_waitingForContentPolicy
/Volumes/Data/worker/Apple-Tahoe-Debug-Build/build/Source/WebCore/loader/DocumentLoader.cpp
https://bugs.webkit.org/show_bug.cgi?id=320913
rdar://183941470
Reviewed by Alex Christensen.
318278@main turned the CFNetwork NW loader on unconditionally. For
multipart/x-mixed-replace it hands the network process the follow-up parts,
their
data and the end of the load without waiting for the previous part's response
completion handler, whose content-policy check is asynchronous
(DocumentLoader::responseReceived() -> checkContentPolicy() IPCs to the
UIProcess).
313118@main made NetworkResourceLoader tolerate the extra responses by queuing
the response completion handlers in a Deque instead of overwriting a single one,
but it kept forwarding every message to the WebProcess immediately. The
WebProcess cannot process anything past a response it has not validated yet: a
follow-up response hits ASSERT(!m_waitingForContentPolicy) in
DocumentLoader::responseReceived(), and a follow-up didFinishLoading() runs
SubresourceLoader::didFinishLoading() through releaseResources(), which clears
the loader's identifier, so WebResourceLoader never sends
ContinueDidReceiveResponse and the load hangs.
Re-serialize delivery, restoring the one-part-at-a-time semantics the legacy
NSURLSession loader provided. didReceiveResponse() claims the pipeline via
m_isProcessingResponse and wraps the completion handler so that it is released
once the response is resolved, which for a main resource is when the WebProcess
answers ContinueDidReceiveResponse. While the pipeline is claimed, every
follow-up message is held in m_deferredMessages, and it is replayed in order
once
the response is released, stopping at the next response so it too waits.
The state is tracked explicitly rather than derived from
m_responseCompletionHandlers for two reasons. didReceiveResponse() can take
asynchronous steps before appending the handler (processClearSiteDataHeader()),
and nothing may be delivered in that window. It also resolves responses without
appending anything at all: when a main resource is blocked by CSP
frame-ancestors
or X-Frame-Options, by COOP/COEP, by NetworkLoadChecker::validateResponse(), by
content filtering, or is dropped for keepalive, it answers PolicyAction::Ignore
having sent no DidReceiveResponse. Messages queued behind such a response are
dropped rather than replayed, so that WebContent is never handed the body of a
part the network process just blocked, nor a DidReceiveData with no preceding
DidReceiveResponse. Deferred messages are likewise dropped with
PolicyAction::Ignore on teardown so their completion handlers are still
answered,
and the queue is bounded so a WebProcess that never answers cannot grow the
network process' memory without limit.
This is a workaround for the CFNetwork bug, so it is gated on the new
HAVE(BROKEN_MULTIPART_RESPONSE_FLOW_CONTROL), on by default on COCOA ports. A
FIXME points at rdar://185073080 to turn it off on platforms that have the
CFNetwork fix.
Nothing outside multipart is affected: m_isProcessingResponse is false when
those
messages arrive for subresources and for single-response loads.
No new tests, unskipped existing test.
* LayoutTests/platform/mac-wk2/TestExpectations:
* Source/WTF/wtf/PlatformHave.h:
* Source/WebKit/NetworkProcess/NetworkResourceLoader.cpp:
(WebKit::NetworkResourceLoader::~NetworkResourceLoader):
(WebKit::NetworkResourceLoader::convertToDownload):
(WebKit::NetworkResourceLoader::didReceiveResponse):
(WebKit::NetworkResourceLoader::didReceiveBuffer):
(WebKit::NetworkResourceLoader::didFinishLoading):
(WebKit::NetworkResourceLoader::didFailLoading):
(WebKit::NetworkResourceLoader::continueDidReceiveResponse):
(WebKit::NetworkResourceLoader::responseProcessingCompleted):
(WebKit::NetworkResourceLoader::deliverDeferredMessages):
(WebKit::NetworkResourceLoader::cancelDeferredMessages):
(WebKit::NetworkResourceLoader::failDueToExcessiveDeferredMessages):
* Source/WebKit/NetworkProcess/NetworkResourceLoader.h:
Canonical link: https://commits.webkit.org/319418@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
