On WSL2, terminating debugger does not release port, so browser requires restart

[Taskle]

Describe the bug Note that this issue does NOT occur in the "legacy-chrome" extension and is the main problem I have hit since switching from type "legacy-chrome" to "type chrome". It's also an issue that I've had from the beginning of time using this extension, so it's not a new issue, but it is a major blocker to using the feature.

To Reproduce Steps to reproduce the behavior:

1. Get the latest VSCode version on WSL2 with windows running latest Chrome, and WSL2 running VSCode.
2. Use launch.json config as follows:

{
      "type": "chrome",
      "request": "attach",
      "port": 9222,
      "name": "Chrome React app debugger",
      "url": "http://localhost:3000*",
      "webRoot": "${workspaceFolder}/app",
      "sourceMapPathOverrides": {
        "webpack:///./~/*": "${workspaceFolder}/node_modules/*",
        "webpack:///./*": "${workspaceFolder}/*",
        "webpack:///*": "*",
        "webpack:///src/*": "${workspaceFolder}/*",
        "/*": "${workspaceFolder}/*"
      }
    }

4. Open your Windows chrome to a given page, e.g. http://localhost:3000
5. Click the "play" button to start the debugger. Observe that it works as expected. Then either (a) click the "Disconnect" button OR close the browser window. Observe that the debugger stops.

Expected behavior: Going to https://localhost:3000 in a new tab loads the page as expected. Actual behavior: the page is stuck on loading and requires a computer restart OR "netstat -ano | findstr :9222" and then "Taskkill /PID <PID> /F" to release the port and make it usable again (which kills all chrome windows, so if you have multiple tabs open like I do, it's a productivity killer).

Log File vscode-debugadapter-3542ee4c.json.gz

VS Code Version: 1.79.1 (system setup)

Additional context If you use the legacy vscode extension with the following setup instead of the above, it disconnects properly:

{
      "type": "legacy-chrome",
      "request": "attach",
      "port": 9222,
      "name": "Chrome React app debugger",
      "urlFilter": "http://localhost:3000*",
      "webRoot": "${workspaceFolder}/app",
      "sourceMapPathOverrides": {
        "webpack:///./~/*": "${workspaceFolder}/node_modules/*",
        "webpack:///./*": "${workspaceFolder}/*",
        "webpack:///*": "*",
        "webpack:///src/*": "${workspaceFolder}/*",
        "/*": "${workspaceFolder}/*"
}

[MikeVensel]

This is incredibly annoying in my day-to-day use of vs code. Is there any timeline for when this will be resolved?

[Taskle]

Just checking in -- @connor4312 does this look worthy of prioritization to you?

Since it's a blocker to adopting the debugger, but I recognize it only affects WSL2 customers on React, I'm curious to get your perspective, e.g. if we should revert back to / stay on the legacy version that doesn't have this bug.

[MikeVensel]

Just checking in -- @connor4312 does this look worthy of prioritization to you?

Since it's a blocker to adopting the debugger, but I recognize it only affects WSL2 customers on React, I'm curious to get your perspective, e.g. if we should revert back to / stay on the legacy version that doesn't have this bug.

I am using it for Angular v15 in WSL2. It isn't just a React problem.

[connor4312]

I'm not clear on the steps you do between "click the "Disconnect" button OR close the browser window" and "Going to https://localhost:3000/". Are you using the same browser that was being debugged? A new browser?

A screen cap may be easiest :) https://gifcap.dev/ is useful

It's likely that the recent 1.80 update fixed this issue for WSL, but I am still interested in knowing the steps because it may similarly effect SSH, tunnels, and dev containers.

[Taskle]

@connor4312 I realize I had a typo in my original description (fixed) - I said "browser restart" but meant "computer restart", my apologies!

So to answer your question, both cases have the same behavior, namely that whether I reuse the same browser window or close the browser entirely and reopen it, localhost:3000 hangs permanently and requires a computer restart OR "netstat -ano | findstr :9222" and then "Taskkill /PID /F" to release the port

[Taskle]

Hi there @connor4312, just checking in on this as it's still a problem. Any update?