Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 36e79ac25b963f8abeb3a6440e9df0008a217aaa
https://github.com/WebKit/WebKit/commit/36e79ac25b963f8abeb3a6440e9df0008a217aaa
Author: Qianlang Chen <[email protected]>
Date: 2026-07-08 (Wed, 08 Jul 2026)
Changed paths:
A
LayoutTests/http/tests/site-isolation/inspector/network/main-frame-resource-appears-in-network-domain-expected.txt
A
LayoutTests/http/tests/site-isolation/inspector/network/main-frame-resource-appears-in-network-domain.html
M Source/WebCore/inspector/InspectorIdentifierRegistry.cpp
Log Message:
-----------
[Site Isolation] Web Inspector: main-frame subresource sometimes missing from
Network under Site Isolation
https://bugs.webkit.org/show_bug.cgi?id=318472
Reviewed by BJ Burg.
Under Site Isolation the inspector backend could report an inconsistent
loaderId for the main frame: the id in the Page.getResourceTree snapshot
did not match the id carried by the network events for resources loaded
by that same frame. Because of the mismatch, a subresource requested by
the main frame (for example via fetch()) could intermittently be handled
by the frontend as a provisional load and not attributed to the frame.
The frontend attributes a resource to a frame by matching loaderIds. A
resource gets its loaderId from the UIProcess ProxyingNetworkAgent,
which derives it freshly from the live document's
ScriptExecutionContextIdentifier. The frame gets its loaderId once,
from the page target's Page.getResourceTree snapshot, which came from
BackendIdentifierRegistry::loaderId() -- a value memoized in a map
keyed by the raw DocumentLoader*. That cached value could go stale
(minted while the loader was still provisional, or held against a
DocumentLoader* whose address was later reused), so getResourceTree
reported a loaderId that no longer matched the frame's live document.
When the two disagree, NetworkManager._addResourceToFrame treats the
resource as the start of a provisional navigation and hands it to
startProvisionalLoad() instead of adding it. Because staleness depended
on timing and pointer reuse, the failure was intermittent.
Fix BackendIdentifierRegistry::loaderId() to compute the id directly
from the loader's current document instead of memoizing.
protocolLoaderId() is a deterministic function of the document's
ScriptExecutionContextIdentifier, so it now always matches what network
events report; the map is kept only for the pre-document fallback. Its
sole caller under Site Isolation is
InspectorPageAgent::buildObjectForFrame() with the committed
documentLoader(), so frame->document() always reflects that loader's
own document. The pre-Site-Isolation LegacyIdentifierRegistry path is
unaffected.
Test:
http/tests/site-isolation/inspector/network/main-frame-resource-appears-in-network-domain.html
- Add the test we wanted to have, the main-frame variant of the sibling
test cross-origin-iframe-resource-appears-in-network-domain.html,
which would intermittently timing out without this patch.
*
LayoutTests/http/tests/site-isolation/inspector/network/main-frame-resource-appears-in-network-domain-expected.txt:
Added.
*
LayoutTests/http/tests/site-isolation/inspector/network/main-frame-resource-appears-in-network-domain.html:
Added.
* Source/WebCore/inspector/InspectorIdentifierRegistry.cpp:
(Inspector::BackendIdentifierRegistry::loaderId):
Canonical link: https://commits.webkit.org/316758@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
