Debugger tries to attach instead of launch

[thalestestoni]

Describe the bug If starting debugger with launch config when chrome is running, vscode tries to attach instead of launch.

To Reproduce Steps to reproduce the behavior:

1. Open Google Chrome.
2. Open vscode.
3. Run react project (CRA template) on terminal.
4. Start debugging on vscode (press f5).
5. See error "Unable to attach to browser".

launch.json file:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Launch Chrome",
      "type": "chrome",
      "request": "launch",
      "url": "http://localhost:3000",
      "webRoot": "${workspaceFolder}/src",
      "sourceMapPathOverrides": {
        "webpack:///src/*": "${webRoot}/*"
      },
    }
  ]
}

Log File vscode-debugadapter-3d518fcb.json.gz

VS Code Version: vscode 1.74.3

Additional context Debugger extension used: vscode-js-debug v1.74.1 Google chrome version: 109.0.5414.75

[connor4312]

It looks like the log file is truncated, please try to re-create it and upload. For best results, make sure to stop debugging before copying the log file.

[thalestestoni]

Log file vscode-debugadapter-dafc7f0f.json.gz

The length of this log file is the same as the previously loaded log file (4kb). The debugger stops automatically before logging any log :(

[thalestestoni]

Log file generated when google chrome is closed before starting the debugger: vscode-debugadapter-b69d4c47.json.gz. But, as commented, the error only occurs when chrome is running before starting the debugger.

[connor4312]

Chrome has a 'singleton lock' where it reuses a single process instance when launched. We need to get around that in order to launch Chrome in debug mode, and to do so the debugger launches chrome with a --userDataDir=... that's unique per workspace.

The behavior you're describing sounds as if the Chrome process is getting reused somehow, perhaps if Chrome is ignoring the userDirFlag, or that your normal Google Chrome instance is actually launching from the extension's user data dir.

Could you navigate to chrome://version in both your normal browser and debug browser, and share the command line and profile path shown on that page?

[thalestestoni]

Normal browser

Command line: "C:\Program Files\Google\Chrome\Application\chrome.exe" --flag-switches-begin --disable-quic --flag-switches-end

Profile path: C:\Users\103708\AppData\Local\Google\Chrome\r_kjxoany\Default

Debug browser

Command line: "C:\Program Files\Google\Chrome\Application\chrome.exe" --disable-background-networking --disable-background-timer-throttling --disable-backgrounding-occluded-windows --disable-breakpad --disable-client-side-phishing-detection --disable-default-apps --disable-dev-shm-usage --disable-renderer-backgrounding --disable-sync --metrics-recording-only --no-first-run --no-default-browser-check --user-data-dir="c:\Users\103708\AppData\Roaming\Code\User\workspaceStorage\199293ef91f2e28163fa9e92ae580248\ms-vscode.js-debug\.profile" --remote-debugging-pipe --flag-switches-begin --disable-quic --flag-switches-end about:blank

Profile path: C:\Users\103708\AppData\Local\Google\Chrome\r_kjxoany\Default

Debug console

One thing i noticed is that in the debug console the following error message is displayed:

Could not read source map for chrome-extension://gighmmpiobklfepjocnamgkkbiglidom/polyfill.js: Unexpected 503 response from chrome-extension://gighmmpiobklfepjocnamgkkbiglidom/browser-polyfill.js.map: Unsupported protocol "chrome-extension:"

[connor4312]

Yep, that's hwhat's happening. We're passing the --user-data-dir apparently correctly to Chrome, but the "profile path" is your default user profile. That is very much not correct.

[thalestestoni]

Ok Peet, understood. As my browser is managed by the company I work for, I will check with the responsible team the settings that are being applied in the browser and if there is something that is ignoring the properties passed. Thank you very much!

[connor4312]

One more thing to look at. Reading through Chromium's source, it seems it should log stderr if it falls back to the default user data dir path. To capture that info, please run one more time with "trace": {"logFile": "${workspaceFolder}/trace.txt", "stdio": true},. That will make a trace.txt in your folder and include the browser's stderr which may contain an error.

[thalestestoni]

trace.txt

[connor4312]

Sorry, I should clarify, please do that without another instance of Chrome already running. That way it'll boot successfully, but should hopefully print a message saying why it falls back to the default user data dir and ignores the flag.

[thalestestoni]

Oh, ok. I sent an email to [email protected] with the trace file because now contains senstive data.