Blazor browser crashes

[connor4312]

Hi, I came here from https://devblogs.microsoft.com/aspnet/blazor-webassembly-3-2-0-preview-3-release-now-available/
And seems like pwa-msedge doesn't work.
I have latest MS Edge installed ( Version 80.0.361.69 (Official build) (64-bit) ) "debug.javascript.usePreview": true and this is my launch.json:

{
            "name": ".NET Core Debug Blazor Web Assembly in Edge",
            "type": "pwa-msedge",
            "request": "launch",
            "timeout": 30000,
            "url": "https://localhost:5001",
            "webRoot": "${workspaceFolder}/Server",
            "inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}"
}

When I trying to start debug I see this error:

Unable to launch browser: "Failed to launch browser!
[0327/171300.005:ERROR:file_io.cc(89)] ReadExactly: expected 120, observed 40

TROUBLESHOOTING: https://github.com/GoogleChrome/puppeteer/blob/master/docs/troubleshooting.md

Can you help me find out what's wrong?

_Originally posted by @vchirikov in microsoft/vscode-js-debug#405

I've been getting a steady trickle of reports on this from people using Blazor, reported on both Chrome and Edge. @digeff reports that they haven't seen this on VS, and I haven't received reports on this from any non-Blazor users. Is there anything Blazor is doing differently that could cause this? Trees to bark up would also be appreciated 😛

[captainsafia]

@connor4312 The debugging setup in Blazor is definitely a little different than a standard JS debugging experience.

I'm a little surprised at the exception thrown here. It seems to be coming from the Chrome launcher itself, which comes into play before the Blazor app has launched. The entire flow for debugging Blazor WASM in VS Code looks something like this (assuming the user uses blazorwasm debug type).

1. User presses F5.
2. VS Code passes the debugging request to our debugging config resolver.
3. The blazorwasm config provider spawns a process running dotnet run in the current working directory (or a cwd provided by the user).
4. The blazorwasm config provider starts a JS debugging session throw either pwa-msedge or pwa-chrome.
5. The JS debugger sends a request to http://localhost:5001/_framework/debug/ws-proxy/...
6. The Blazor server receives the request from HelloConsole folder does not exist. The actual folder name is ConsoleApp... #5 and starts the Mono debug proxy. The JS debugger sends CDP messages to this endpoint.
7. The Chrome browser is started.

You might have some more insights, @connor4312, about the exact ordering of 5-7. Perhaps the fact that the JS debugger communicates with the application server causes some issues here? Although I dunno why that would surface the stack traces we are seeing from Chrome.

[connor4312]

It seems like we haven't gotten any trace logs yet, so I've asked in the other issue to collect some. That should help understand the ordering.

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[aventus13]

Please see attached for the trace logs
vscode-debugadapter-0.json.gz

[connor4312]

That appears to be a separate issue, looks like the Blazor proxy is not running:

"Unable to launch browser: "Could not open ws://localhost:5001/_framework/debug/ws-proxy?browser=ws%3A%2F%2F127.0.0.1%3A50835%2Fdevtools%2Fbrowser%2F57772b19-838c-45c9-9a60-20ea02b21f62""

(thrown from new Websocket(...).on('error')

[aventus13]

Should I raise a separate issue for it then? Am I missing some setup? How do I run the Blazor proxy?

[captainsafia]

@aventus13 You're in our repo now. Can you share the version of Blazor that you were using when you encountered this issue?

Thanks,
Safia

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[pranavkm]

Thanks for contacting us. We're closing this issue as there was no community involvement here for quite a while now.

You can learn more about our triage process and how we handle issues by reading our Triage Process writeup.

[vchirikov]

And it still doesn't work :D

I tried:

dotnet new blazorwasm --no-restore

launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "blazorwasm",
            "name": "Launch and Debug Blazor WebAssembly Application",
            "request": "launch",
            "browser": "edge",
        }
    ]
}

ms-dotnettools.blazorwasm-companion-1.1.0
dotnet 6.0

cc: @pranavkm @captainsafia

[captainsafia]

@vchirikov Can you file another issue? The problem you are reporting is distinct from the one discussed here.

[vchirikov]

@captainsafia I found the reason, it's occupied port 9222.
vs / vscode use the hard-coded value --remote-debugging-port=9222 and I'm already using the port in another browser.
That's why msedge crashes. By the way, Rider uses --remote-debugging-port=0 and it worked without any investigations :) I think vs / vscode should check open ports before starting debugging or use a random port.

[captainsafia]

@captainsafia I found the reason, it's occupied port 9222. vs / vscode use the hard-coded value --remote-debugging-port=9222 and I'm already using the port in another browser. That's why msedge crashes. By the way, Rider uses --remote-debugging-port=0 and it worked without any investigations :) I think vs / vscode should check open ports before starting debugging or use a random port.

I believe VS already uses a random port and VS Code looks for available ports on the machine to use (ref) so I'm not sure that would explain the issue.

In any case, I'm glad you were able to find a resolution.

[vchirikov]

@captainsafia your code doesn't work: