[Site Isolation] Implement Page.getResourceTree on the UIProcess ProxyingPageAgent

1c2a6d9

LayoutTests/http/tests/site-isolation/inspector/page/resource-tree-cross-origin-iframe.html

+let { frameTree } = await WI.backendTarget.PageAgent.getResourceTree();
+
+InspectorTest.expectEqual(child.frame.parentId, frameTree.frame.id, "Child frame's parentId should match main frame's id.");
+InspectorTest.expectEqual(child.frame.name, "child-frame", "Child frame's name attribute should be reported.");
+
+// FIXME: The inspectedPage's WebFrameProxy never observes the cross-origin
+// child's didCommitLoadForFrame, so url() and documentSecurityOriginData() remain stale.

WebKit Site Isolation places cross-origin iframes in separate WebContent processes. The UIProcess maintains a WebFrameProxy tree that aggregates frame identity across all of those processes. The ProxyingPageAgent is the UIProcess-side inspector agent that multiplexes the WebKit Inspector Protocol across WebContent processes; its backendTarget represents the aggregated web-page target visible to the frontend.

This commit implements Page.getResourceTree on the UIProcess ProxyingPageAgent by recursively walking WebFrameProxy::childFrames(), which spans every WebContent process. New frameName(), childFrames(), and a null-guarded documentSecurityOriginData() are added on WebFrameProxy. NetworkManager is guarded against clobbering the live per-page frame tree when the multiplexing backendTarget initializes. Critically, the UIProcess WebFrameProxy never receives didCommitLoadForFrame for cross-origin children — so the new walk returns correct structural data (frame IDs, parent linkage, name) but stale/wrong URL and security origin data for cross-origin frames, a gap the commit explicitly defers to follow-up bugs.

Before:                                  After:
  Inspector Frontend                       Inspector Frontend
    └─► per-page PageAgent.getResourceTree    └─► backendTarget ProxyingPageAgent.getResourceTree
          └─► WebContent A only                       └─► UIProcess WebFrameProxy tree
                (cross-origin: invisible)                   ├─► main frame [A]  url/origin: live
                                                            └─► cross-origin [B]  url/origin: STALE
                                                                  └─► grandchild [A]  ⚠ ID collision

Significance

This is the foundational step toward full inspector visibility across Site Isolation process boundaries — cross-origin child frames in remote processes were previously invisible to the inspector frontend. It also opens new UIProcess-side paths that touch security origin data, and the commit explicitly acknowledges that cross-origin URL and origin reporting remain stale and incomplete.

Audit directions

Frame ID collisions. The commit explicitly flags (bug 316663) that FrameIdentifier low 32 bits collide when a grandchild is in the same process as the main frame — main(A) → child(B) → grandchild(A) — and the current walk emits these colliding IDs. Any inspector logic that uses frame IDs as unique keys for security decisions could confuse grandchild(A) with main(A), potentially enabling a cross-origin frame to impersonate the main frame's inspector identity.
The new documentSecurityOriginData() null guard was added because the previous securityOrigin() ASSERT-failed on uncommitted frames that have no established origin yet. A race between a frame commit and a getResourceTree call could yield a null or stale origin for a frame in mid-commit — worth probing whether the null path can be triggered in a way that suppresses a cross-origin origin check downstream.
The NetworkManager bootstrap guard skips getResourceTree for TargetType.WebPage — if this target type check can be bypassed or the type is set incorrectly, an empty snapshot could clobber the live inspector frame tree, hiding cross-origin frames from the security inspector view entirely.