Fix WebWorker hang when debugging Blazor WASM apps in Visual Studio

[ilonatommy]

Summary

When debugging a Blazor WebAssembly app that uses Web Workers (via the dotnet new webworker template, see dotnet/aspnetcore#65037) in Visual Studio, the worker thread hangs indefinitely during startup. The app never completes initialization and the worker appears stuck at importing worker's module.

await using var module = await jsRuntime.InvokeAsync<IJSObjectReference>("import", "./_content/WorkerLib/dotnet-web-worker-client.js");

This PR fixes two issues in the BrowserDebugProxy (MonoProxy) that together cause the hang.

You can use this app to see the problem: BlazorAppRepro.zip

Root Cause

Issue 1 — Worker never resumed after Chrome pauses it on attach:

When VS sends Target.setAutoAttach({ waitForDebuggerOnStart: true }), Chrome pauses all new worker threads until the debugger explicitly sends Runtime.runIfWaitingForDebugger. The proxy's Target.attachedToTarget handler for workers only called CreateWorkerExecutionContext() but never sent Runtime.runIfWaitingForDebugger, leaving the worker frozen before any JS executed.

Issue 2 — Debugger.paused event forwarded to IDE instead of being resumed:

Even after resuming the worker, VS's JavaScript debugger auto-attaches with breakOnLoad: true, which fires a Debugger.paused event on the worker session. In OnDebuggerPaused's default case, when JustMyCode is enabled and the execution context isn't runtime-ready (IsRuntimeReady == false), the handler returns false — forwarding the pause to VS. VS's JS debugger receives the pause but doesn't resume it, leaving the worker stuck. Shortly after, the CDP connection crashes with ObjectDisposedException.

Changes

MonoProxy.cs — two targeted fixes:

1. Target.attachedToTarget handler: For worker targets, send Runtime.runIfWaitingForDebugger after creating the worker execution context. This tells Chrome to unpause the worker thread.

2. OnDebuggerPaused default case: When the session belongs to a worker (detected via context.ParentContext != null) and the runtime isn't ready yet, call SendResume instead of returning false. This prevents the pause from being forwarded to the IDE and lets the worker continue booting its WASM runtime.

Testing

Manually verified with a Blazor WASM Standalone app + webworker library project in VS 2022 (by replacing the .dlls VS uses):

• Before fix: F5 → worker hangs at startup, app stuck at "Creating worker..."
• After fix: F5 → worker runs to completion, app shows correct results, main-thread breakpoints (e.g., in Home.razor) hit correctly

Known Limitation

Breakpoints in C# code running inside the Web Worker (e.g., [JSExport] methods in the worker library) do not get hit. The debug proxy currently only attaches its SDB agent to the main page's WASM runtime, not the worker's second runtime. This is a pre-existing architectural limitation and is out of scope for this PR but I would like to have it solved as well. Any ideas on how to do it are welcome.

Contributes to dotnet/aspnetcore#65823.

[dotnet-policy-service]

Tagging subscribers to this area: @steveisok, @thaystg, @dotnet/dotnet-diag
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

Fixes a Visual Studio debugging hang for Blazor WebAssembly apps that use Web Workers by ensuring worker targets are resumed correctly when Chrome/VS pause them during attach/startup, preventing the worker from getting stuck before executing its module import.

Changes:

• On Target.attachedToTarget for worker, send Runtime.runIfWaitingForDebugger after creating the worker execution context.
• In OnDebuggerPaused (default case), when JustMyCode is enabled and a worker session isn’t runtime-ready yet, resume the worker instead of forwarding the pause to the IDE.

---

You can also share your feedback on Copilot code review. Take the survey.