Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 34201b414d6591dc899d5dfba704c6217ab1fabb
https://github.com/WebKit/WebKit/commit/34201b414d6591dc899d5dfba704c6217ab1fabb
Author: Qianlang Chen <[email protected]>
Date: 2026-03-04 (Wed, 04 Mar 2026)
Changed paths:
M
LayoutTests/http/tests/site-isolation/inspector/console/message-from-iframe-expected.txt
M
LayoutTests/http/tests/site-isolation/inspector/console/message-from-iframe.html
M
LayoutTests/http/tests/site-isolation/inspector/console/message-from-worker-expected.txt
M
LayoutTests/http/tests/site-isolation/inspector/console/message-from-worker.html
M
LayoutTests/http/tests/site-isolation/inspector/console/resources/console-messages.html
M
LayoutTests/http/tests/site-isolation/inspector/console/resources/embedded-cross-origin.html
M
LayoutTests/http/tests/site-isolation/inspector/console/resources/embedded-same-origin.html
M
LayoutTests/http/tests/site-isolation/inspector/console/resources/worker-in-iframe.html
M
LayoutTests/http/tests/site-isolation/inspector/target/resources/leaf-iframe.html
M
LayoutTests/http/tests/site-isolation/inspector/target/resources/middle-iframe.html
M LayoutTests/http/tests/site-isolation/inspector/target/target-expected.txt
M LayoutTests/http/tests/site-isolation/inspector/target/target.html
M LayoutTests/platform/mac-wk2/TestExpectations
M Source/JavaScriptCore/inspector/agents/InspectorTargetAgent.cpp
M Source/WebKit/UIProcess/Inspector/WebPageInspectorController.cpp
M Source/WebKit/UIProcess/Inspector/WebPageInspectorController.h
M Source/WebKit/UIProcess/ProvisionalFrameProxy.cpp
M Source/WebKit/UIProcess/WebFrameProxy.cpp
M Source/WebKit/WebProcess/Inspector/FrameInspectorTarget.cpp
M Source/WebKit/WebProcess/Inspector/FrameInspectorTarget.h
Log Message:
-----------
[Site Isolation] Web Inspector: Console message from cross-origin iframe
appended by JS don't show up
https://bugs.webkit.org/show_bug.cgi?id=307733
Reviewed by BJ Burg.
When a cross-origin iframe is added dynamically, there is a delay
between creating a new WebFrameProxy and eventually loading the frame
in a new web process. A LocalFrame is first created in the original
web process, and only at a certain point -- when the new provisional
frame "commits" -- will a second LocalFrame be made in the destination
process. This gives the frontend an opportunity to perform initializing
work (e.g. Console.enable) while the WebFrameProxy was still tied to
the old web process's frame target. Thus, the new frame target was never
set up to push any console messages to the frontend.
Fix this issue by implementing support for provisional frame targets
in a similar fashion to provisional page targets. In summary, this is
what the frontend sees:
- Normally, there's only one frame target per frame element.
- When a frame navigates, didCreateProvisionalFrame occurs, surfacing a
new provisional frame target to the frontend. There are now two
frame targets referring to the same frame element.
- If loading fails (e.g. was blocked), willDestroyProvisionalFrame
occurs, destroying the provisional frame target.
- When the provisional frame commits, didCommitProvisionalFrame occurs,
destroying the old committed frame target and transitioning the
provisional target to committed state. Destroying either target brings
us back to one regular frame target per frame.
This procedure compares closely to how provisional page loading works.
(There is still additional work needed to refine the timing of
destroying provisional frame targets when loading in cancelled. The
underlying issue should occur infrequently. See https://webkit.org/b/308182.)
For WebFrame on the web process side, before a provisional frame
commits, the coreFrame is a remote frame, and there's a separate
provisional LocalFrame member. So unlike in the page's case,
FrameInspectorTarget must check for the provisional frame and route
commands accordingly.
As the frame id stays the same across even a cross-origin navigation,
we update the id that we present to the frontend to also include the
web process id in order to keep target ids still unique.
Tests: http/tests/site-isolation/inspector/target/target.html,
http/tests/site-isolation/inspector/console/message-from-iframe.html
Update the target.html test to include more scenarios involving cross-
origin loading and also adding grandchild iframes using JavaScript.
The message-from-iframe.html test now also progressed. Loading
grandchild iframes only when document.body.onload is added to ensure
consistent loading and logging order. Avoid logging from both
childIframe.onload and document.body.onload inside the child iframe for
similar reasons.
The two cases in target.html that cancel provisional loading revealed
a bug that loading could be canceled while handling
addAllowedFirstPartyForCookies, invalidating the eventual resource
loading when that network process operation completes. Skip these two
cases for now and filed https://webkit.org/b/309172 as a follow-up.
(I could only repro this bug with this inspector test on a debug+asan
build. It should be very hard to repro or run into otherwise.)
A test case in message-from-worker.html involving cross-origin-iframe-
owned worker still fails due to not having SI support in Worker domain.
Revise that test case similarly to fix flakiness in test output.
*
LayoutTests/http/tests/site-isolation/inspector/console/message-from-iframe-expected.txt:
*
LayoutTests/http/tests/site-isolation/inspector/console/message-from-iframe.html:
*
LayoutTests/http/tests/site-isolation/inspector/console/message-from-worker-expected.txt:
*
LayoutTests/http/tests/site-isolation/inspector/console/message-from-worker.html:
*
LayoutTests/http/tests/site-isolation/inspector/console/resources/console-messages.html:
*
LayoutTests/http/tests/site-isolation/inspector/console/resources/embedded-cross-origin.html:
*
LayoutTests/http/tests/site-isolation/inspector/console/resources/embedded-same-origin.html:
*
LayoutTests/http/tests/site-isolation/inspector/console/resources/worker-in-iframe.html:
*
LayoutTests/http/tests/site-isolation/inspector/target/resources/leaf-iframe.html:
*
LayoutTests/http/tests/site-isolation/inspector/target/resources/middle-iframe.html:
* LayoutTests/http/tests/site-isolation/inspector/target/target-expected.txt:
* LayoutTests/http/tests/site-isolation/inspector/target/target.html:
* LayoutTests/platform/mac-wk2/TestExpectations:
* Source/JavaScriptCore/inspector/agents/InspectorTargetAgent.cpp:
(Inspector::InspectorTargetAgent::sendMessageFromTargetToFrontend):
* Source/WebKit/UIProcess/Inspector/WebPageInspectorController.cpp:
(WebKit::getTargetID):
(WebKit::WebPageInspectorController::sendMessageToInspectorFrontend):
(WebKit::WebPageInspectorController::didCreateFrame):
(WebKit::WebPageInspectorController::willDestroyFrame):
(WebKit::WebPageInspectorController::didCreateProvisionalFrame):
(WebKit::WebPageInspectorController::willDestroyProvisionalFrame):
(WebKit::WebPageInspectorController::didCommitProvisionalFrame):
(WebKit::WebPageInspectorController::shouldManageFrameTargets const):
* Source/WebKit/UIProcess/Inspector/WebPageInspectorController.h:
* Source/WebKit/UIProcess/ProvisionalFrameProxy.cpp:
(WebKit::ProvisionalFrameProxy::~ProvisionalFrameProxy):
* Source/WebKit/UIProcess/WebFrameProxy.cpp:
(WebKit::WebFrameProxy::prepareForProvisionalLoadInProcess):
(WebKit::WebFrameProxy::commitProvisionalFrame):
* Source/WebKit/WebProcess/Inspector/FrameInspectorTarget.cpp:
(WebKit::FrameInspectorTarget::identifier const):
(WebKit::FrameInspectorTarget::connect):
(WebKit::FrameInspectorTarget::disconnect):
(WebKit::FrameInspectorTarget::sendMessageToTargetBackend):
(WebKit::FrameInspectorTarget::toTargetID):
* Source/WebKit/WebProcess/Inspector/FrameInspectorTarget.h:
Canonical link: https://commits.webkit.org/308662@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
