← All issues

[Site Isolation] Cross-process resource and loaderId aggregation in Page.getResourceTree

df1a3bd

Under Site Isolation each cross-origin frame runs in its own WebContent process, but CachedResourceLoader (holding cached subresources) lives in the hosting process, not the UIProcess. The Web Inspector's Page.getResourceTree previously returned correct frame structure and URLs for cross-origin frames but left loaderId and resources empty, having no cross-process retrieval path.

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

for (let attempt = 0; attempt < 50; ++attempt) {
({ frameTree } = await WI.backendTarget.PageAgent.getResourceTree());
child = frameTree.childFrames?.[0];
if (child && (child.resources || []).some((r) => r.url.endsWith("/resource-tree-subframe-style.css")))
break;
await new Promise((resolve) => setTimeout(resolve, 50));
}

The proxy now walks the WebFrameProxy tree, groups frame IDs by hosting process, sends each process a typed GetFrameResourceData IPC request carrying only that process's frame IDs, and assembles the replied structs into a unified tree via a CallbackAggregator. The command is made asynchronous to accommodate the round-trips; secure decoding is auto-generated from a new serialization.in file.

This adds a new async multi-process IPC path in the Web Inspector — a CallbackAggregator spanning multiple WebContent processes — exactly the kind of code where frame-lifetime bugs and TOCTOU races appear.

🔒

New async cross-process inspector IPC path — multi-process coordination edge cases and frame identity handling warrant security investigation.

Subscribe to read more