dotnet / dotnet/runtime

Blazor WASM debugger permanently broken when cross-origin iframe loads (MonoProxy attaches to OOPiF CDP target)

Open
#127,850 4 comments 0 reactions 0 assignees View on GitHub
arch-wasm area-Debugger-mono needs-author-action os-browser
Dominant language
C#
Stars
18.3k
Forks
5.6k
PR merge metrics
PR metrics pending

Description

### Description

When a Blazor WASM app contains an `` loading a cross-origin URL, the VS debugger
permanently breaks with "Cannot step, operation not supported" (German: "Springen nicht möglich,
der Vorgang wird nicht unterstützt"). Closing and reopening the browser is the only recovery.

### Root Cause

In `MonoProxy.cs` (src/mono/browser/debugger/BrowserDebugProxy/MonoProxy.cs), the
`Target.attachedToTarget` handler unconditionally calls `AttachToTarget` for every new
target with `type == "page"`:

```csharp
case "Target.attachedToTarget":
{
var targetType = args["targetInfo"]["type"]?.ToString();
if (targetType == "page") // ← too broad
await AttachToTarget(new SessionId(args["sessionId"]?.ToString()), token);

Chrome's Site Isolation renders cross-origin iframes as Out-Of-Process iframes (OOPiF), which appear as
separate CDP targets with type == "page" — identical to the main page. The proxy attaches to the iframe's
session and attempts WASM debugging operations on it. Since the iframe has no WASM runtime, subsequent
Debugger.stepOver (F10) commands fail permanently.

Proposed Fix

The CDP targetInfo for OOPiFs has an openerId field set to the parent target's ID. Main pages have no
openerId. The fix would be to skip iframe targets:

case "Target.attachedToTarget":
{
var targetType = args["targetInfo"]["type"]?.ToString();
var openerId = args["targetInfo"]["openerId"]?.ToString();

// Skip OOPiF (cross-origin iframe) targets — they appear as type="page" but
// have an openerId referencing the parent frame. Attaching to them causes the
// debugger to fail permanently on the main WASM session.
if (targetType == "page" && string.IsNullOrEmpty(openerId))
await AttachToTarget(new SessionId(args["sessionId"]?.ToString()), token);

Steps to Reproduce

1. Create a standalone Blazor WASM project
2. Add a cross-origin <iframe> (any external URL, e.g. <iframe src="https://example.com" />)
3. Start debugging with VS 2026 (F5)
4. Set a breakpoint anywhere and hit it
5. Press F10 (Step Over) → "Cannot step, operation not supported"

Expected Behavior

Debugger steps normally. Cross-origin iframes should not affect WASM debugging.

Environment

- .NET 10 SDK
- Visual Studio 2026
- Chrome / Edge (Site Isolation enabled by default since Chrome 67)
- Windows 11

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.