Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 635052683f7ac3528bd912d3e5035760ee4b746b
https://github.com/WebKit/WebKit/commit/635052683f7ac3528bd912d3e5035760ee4b746b
Author: Qianlang Chen <[email protected]>
Date: 2026-09-24 (Thu, 24 Sep 2026)
Changed paths:
M
LayoutTests/http/tests/site-isolation/inspector/dom/accessibility-frame-target.html
M
LayoutTests/http/tests/site-isolation/inspector/dom/custom-elements-and-pseudo-elements-frame-target.html
M
LayoutTests/http/tests/site-isolation/inspector/dom/editing-commands-frame-target.html
M
LayoutTests/http/tests/site-isolation/inspector/dom/js-bridge-frame-target.html
M
LayoutTests/http/tests/site-isolation/inspector/dom/query-commands-frame-target.html
A
LayoutTests/http/tests/site-isolation/inspector/runtime/frame-execution-context-after-cross-origin-navigation-expected.txt
A
LayoutTests/http/tests/site-isolation/inspector/runtime/frame-execution-context-after-cross-origin-navigation.html
A
LayoutTests/http/tests/site-isolation/inspector/runtime/resources/frame-execution-context.html
M Source/WebCore/inspector/agents/InspectorDOMAgent.cpp
M Source/WebCore/inspector/agents/InspectorDOMAgent.h
M Source/WebCore/inspector/agents/frame/FrameDOMAgent.cpp
M Source/WebInspectorUI/UserInterface/Controllers/NetworkManager.js
M Source/WebInspectorUI/UserInterface/Models/DOMNode.js
M Source/WebInspectorUI/UserInterface/Models/DOMTree.js
M Source/WebInspectorUI/UserInterface/Models/ExecutionContext.js
M Source/WebInspectorUI/UserInterface/Models/ExecutionContextList.js
M Source/WebInspectorUI/UserInterface/Models/Frame.js
M Source/WebInspectorUI/UserInterface/Protocol/FrameTarget.js
M Source/WebInspectorUI/UserInterface/Protocol/RuntimeObserver.js
M Source/WebInspectorUI/UserInterface/Views/QuickConsole.js
Log Message:
-----------
[Site Isolation] Web Inspector: A frame target's execution contexts never
reach its WI.Frame
rdar://187706267
https://bugs.webkit.org/show_bug.cgi?id=324467
Reviewed by BJ Burg.
Under Site Isolation every frame has its own frame target, and that
target's Runtime agent is the only one that keeps announcing the
frame's main-world realm: InspectorInstrumentation's
didClearWindowObjectInWorld stops routing to PageRuntimeAgent once a
frame has an enabled FrameRuntimeAgent. WI.RuntimeObserver, however,
short-circuited frame-target contexts straight to
WI.FrameTarget.addExecutionContext and never told WI.NetworkManager,
which is where a WI.Frame learns about its contexts. So after any
frame navigated, WI.Frame.pageExecutionContext stayed null forever and
WI.Frame.Event.ExecutionContextAdded never fired again. That silently
drops the frame out of the console's context picker and makes
Web Inspector extension script evaluation fail for it.
Route every executionContextCreated report through WI.NetworkManager,
tagged with the target that reported it, and file it on both the
issuing frame target and the matching WI.Frame as the same object;
several call sites compare contexts by identity. Taking the reporting
target instead of guessing frame.mainResource.target is also a fix in
its own right, because RuntimeManager dispatches on the context's
target and a context identifier only means anything to the agent that
minted it.
For the same reason the target is part of a context's identity.
WI.Frame.addExecutionContext compared a replacement context against
the current page execution context by id alone, which does not hold
across targets: every InjectedScriptManager numbers its realms from 1,
so a replacement frame target's first realm reuses the id the
destroyed target had, and the frame would keep serving the dead one.
Compare the target too, the way WI.DebuggerManager already does.
While the inspector is opening, the page target and the frame target
both announce the same realm with identifiers from their own
InjectedScriptManagers, and the protocol has no way to retract the
duplicate. WI.Frame therefore lets the frame target's report win and
ignores the page target's. That decision reads the frame's current
list rather than latching on the frame: the frontend does not control
which agent enables first, and a latch would leave a frame whose
contexts were cleared between the two reports with no context at all,
which is worse than a duplicate. Making the backend announce each
realm once is a separate change, sensitive to that same ordering.
A frame target reports its realm as soon as the document's window
object is set up, which can arrive before Page.getResourceTree or
Page.frameNavigated has told the frontend the frame exists, and the
report is not repeated. So NetworkManager associates a frame target's
already-reported contexts with a frame when the frame is created, and
again once a navigation has settled, since both Frame.initialize and
Frame.commitProvisionalLoad clear the list and would otherwise discard
what was just associated. A frame nested inside an out-of-process
frame is never added to the frame map at all today, so its context is
reachable only through its frame target; that is tracked in
https://bugs.webkit.org/show_bug.cgi?id=325086.
A context is unusable once the target that minted it is gone, so
NetworkManager drops a removed frame target's contexts from every
frame rather than leaving them to evaluate over a dead connection.
WI.ExecutionContextList.add now reports whether it accepted the
context, so neither WI.Frame nor WI.FrameTarget announces
ExecutionContextAdded for a context the list rejected as a duplicate.
The list also only promoted a context to pageExecutionContext for page
targets, so it now accepts frame targets too -- without that a
frame-target context landed in the list but never became the frame's
page execution context.
WI.DOMNode.querySelector and querySelectorAll answered ids in the
responding agent's own id space while callers look nodes up in the
manager-wide map, so they now hand back the scoped key the way
WI.DOMManager.pushNodeToFrontend already does. Four site-isolation
tests were rescoping those ids by hand and no longer need to.
Also bring FrameDOMAgent's Document payload to parity with
InspectorDOMAgent by setting baseURL and xmlVersion, sharing the
latter's documentBaseURLString helper, and stop QuickConsole's picker
from listing a frame target's context a second time once it is also
reachable through its frame.
inspector/runtime/frame-execution-context-after-navigation.html goes
from timing out to passing under Site Isolation.
Test:
http/tests/site-isolation/inspector/runtime/frame-execution-context-after-cross-origin-navigation.html
The new test covers the cross-origin case, where the frame is in its own
process: its WI.Frame gets a page execution context owned by its frame
target, and navigating the frame within its own site replaces it with
another context from that same frame target. The cross-site case, where
the frame swaps process and a replacement frame target starts numbering
realms from 1 again, is deliberately not covered: a frame does not
survive that swap in the frontend's frame model today; tracked in
https://webkit.org/b/325088.
*
LayoutTests/http/tests/site-isolation/inspector/dom/accessibility-frame-target.html:
*
LayoutTests/http/tests/site-isolation/inspector/dom/custom-elements-and-pseudo-elements-frame-target.html:
*
LayoutTests/http/tests/site-isolation/inspector/dom/editing-commands-frame-target.html:
*
LayoutTests/http/tests/site-isolation/inspector/dom/js-bridge-frame-target.html:
*
LayoutTests/http/tests/site-isolation/inspector/dom/query-commands-frame-target.html:
*
LayoutTests/http/tests/site-isolation/inspector/runtime/frame-execution-context-after-cross-origin-navigation-expected.txt:
Added.
*
LayoutTests/http/tests/site-isolation/inspector/runtime/frame-execution-context-after-cross-origin-navigation.html:
Added.
*
LayoutTests/http/tests/site-isolation/inspector/runtime/resources/frame-execution-context.html:
Added.
* Source/WebCore/inspector/agents/InspectorDOMAgent.cpp:
(WebCore::InspectorDOMAgent::documentBaseURLString):
(WebCore::documentBaseURLString): Deleted.
* Source/WebCore/inspector/agents/InspectorDOMAgent.h:
* Source/WebCore/inspector/agents/frame/FrameDOMAgent.cpp:
(WebCore::FrameDOMAgent::buildObjectForNode):
* Source/WebInspectorUI/UserInterface/Controllers/NetworkManager.js:
(WI.NetworkManager.prototype.frameDidNavigate):
(WI.NetworkManager.prototype.executionContextCreated):
(WI.NetworkManager.prototype._adoptReportedExecutionContexts):
(WI.NetworkManager.prototype._addNewResourceToFrameOrTarget):
(WI.NetworkManager.prototype._createFrame):
(WI.NetworkManager.prototype._handleTargetRemoved):
(WI.NetworkManager):
(WI.NetworkManager.prototype._associateTargetExecutionContextsWithFrame):
(WI.NetworkManager.prototype._disassociateTargetExecutionContextsFromFrame):
* Source/WebInspectorUI/UserInterface/Models/DOMNode.js:
(WI.DOMNode.prototype.querySelector):
(WI.DOMNode.prototype.querySelectorAll):
(WI.DOMNode.prototype.querySelector.toScopedNodeId):
(WI.DOMNode.prototype.querySelectorAll.toScopedNodeIds):
* Source/WebInspectorUI/UserInterface/Models/DOMTree.js:
(WI.DOMTree.prototype._requestRootDOMNode.rootObjectAvailable):
(WI.DOMTree.prototype._requestRootDOMNode):
* Source/WebInspectorUI/UserInterface/Models/ExecutionContext.js:
(WI.ExecutionContext.prototype.get frameId):
* Source/WebInspectorUI/UserInterface/Models/ExecutionContextList.js:
(WI.ExecutionContextList.prototype.add):
* Source/WebInspectorUI/UserInterface/Models/Frame.js:
(WI.Frame.prototype.removeExecutionContextsForTarget):
(WI.Frame.prototype.addExecutionContext):
* Source/WebInspectorUI/UserInterface/Protocol/FrameTarget.js:
(WI.FrameTarget.prototype.addExecutionContext):
* Source/WebInspectorUI/UserInterface/Protocol/RuntimeObserver.js:
(WI.RuntimeObserver.prototype.executionContextCreated):
(WI.RuntimeObserver):
* Source/WebInspectorUI/UserInterface/Views/QuickConsole.js:
(WI.QuickConsole.prototype._frameTargetsWithExecutionContext):
Canonical link: https://commits.webkit.org/321826@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
