When launching a webapp debugging session on an non-mainstream browser, VSCode errors providing no useful info

[Aster89]

Does this issue occur when all extensions are disabled?: Yes, as I haven't installed any.

• VS Code Version: 1.72.0
• OS Version: ArchLinux, up-to-date

Steps to Reproduce:

1. Install qutebrowser
2. Use the following as the your launch.json when debugging a web app, and you'll get an "Unable to attach to browser" error message. Unfortunately such an error gives no info (at least I couldn't find it) to investigate the problem further, should it be on qutebrowser's side

   {
       "version": "0.2.0",
       "configurations": [
           {
               "type": "chrome",
               "request": "launch",
               "runtimeExecutable": "/usr/bin/qutebrowser",
               "runtimeArgs": ["-T", "--qt-flag remote-debugging-port=9229"],
               "name": "Launch Chrome against localhost",
               "url": "http://localhost:1234",
               "webRoot": "${workspaceFolder}"
           }
       ]
   }

(See also the qutebrowser/qutebrowser#7417 (reply in thread).)

[roblourens]

Is it actually listening on that port? You probably need a = in --qt-flag=remote-debugging-port=9229 at least

[connor4312]

Setting trace: true saves verbose logs to a file that will have some more info. This sounds like the remote-debugging-port is not getting applied however.

[Aster89]

Is it actually listening on that port? You probably need a = in --qt-flag=remote-debugging-port=9229 at least

In the thread I linked, I was suggested to change ["-T", "--qt-flag remote-debugging-port=9229"] to ["-T", "--qt-flag", "remote-debugging-port=9229"], which didn't work. ["-T", "--qt-flag=remote-debugging-port=9229"] doesn't solve the problem either.

[Aster89]

Setting trace: true saves verbose logs to a file that will have some more info. This sounds like the remote-debugging-port is not getting applied however.

With that, I get the following in the debug console:

Verbose logs are written to:
/home/enrico/.config/Code - OSS/logs/20221007T205343/exthost1/ms-vscode.js-debug/vscode-debugadapter-fcc4da36.json.gz
usage: qutebrowser [-h] [-B BASEDIR] [-C CONFIG] [-V] [-s OPTION VALUE]
                   [-r SESSION] [-R]
                   [--target {auto,tab,tab-bg,tab-silent,tab-bg-silent,window,private-window}]
                   [--backend {webkit,webengine}]
                   [--desktop-file-name DESKTOP_FILE_NAME] [--untrusted-args]
                   [-l {critical,error,warning,info,debug,vdebug}]
                   [--logfilter LOGFILTER] [--loglines LOGLINES] [-d]
                   [--json-logging] [--nocolor] [--force-color] [--nowindow]
                   [-T] [--no-err-windows] [--qt-arg NAME VALUE]
                   [--qt-flag QT_FLAG] [-D DEBUG_FLAGS]
                   [:command ...] [url ...]
qutebrowser: error: unrecognized arguments: --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 --remote-debugging-pipe

but I've not been able to open the .gz file with gzip -d that-file.gz.

[connor4312]

You can set "includeDefaultArgs": false to disable inclusion of those extra "unrecognized" args.

Usually for the log file I use cat file | gunzip, or upload to https://microsoft.github.io/vscode-pwa-analyzer/index.html

[Aster89]

You can set "includeDefaultArgs": false to disable inclusion of those extra "unrecognized" args.

Usually for the log file I use cat file | gunzip, or upload to https://microsoft.github.io/vscode-pwa-analyzer/index.html

Choosing the file from the website you linked doesn't do anything...

Anyway, here's a gist.

[connor4312]

It looks like the browser does not respond to the Target.attachToBrowserTarget request

[The-Compiler]

It looks like VS Code is still passing --remote-debugging-pipe about:blank. If there's a way to replace that by the --qt-flag equivalent, that might work.

[connor4312]

@joj requested something similar for office scripts, what kind of configuration option would be ideal for y'all to express this?

[joj]

I'm not sure if it'll break people, but ignoreDefaultArgs doesn't ignore that parameter. Being that this is how it works now, it may not be a good idea to change behavior (or maybe it is a good idea, I'm not sure). If we don't want to change behavior, adding a ignoreDefaultConnection parameter may be good enough.

[Aster89]

@joj , is ignoreDefaultConnection something I'd have to add to launch.json?

[joj]

To be super clear: ignoreDefaultConnection doesn't currently exist. What I'm suggesting is adding it (just an idea, may not be a good one). If we added it, you'll add it to the same place where you have ignoreDefaultArgs right now.

[connor4312]

I think a new flag includeLaunchArgs: boolean would work. If that's set to false, we assume that the browser will start debugging on a pipe (to be clear for @Aster89: this is reading debug protocol input on file descriptor 3 and output on file descriptor 4 of the browser process) and figure out how to launch its own page without our intervention.

[joj]

I'm 👍 with that. The default will be true, right? Just to avoid regressions.

[connor4312]

Yea

[connor4312]

This'll be available in the next nightly build of js-debug

[joj]

Tested locally on my scenario and this does indeed fix my issues. Thanks Connor!

[Aster89]

I'd make use of this too, but apparently I can't find the nightly version in the extension view, #163700.

[Aster89]

(After succesfully installing the extension...) It's not clear to me how to make use of it in my original example. Can you guy provide more guidance?

If I simply add a "ignoreLaunchArgs": true, line to the config file, it gets refused as Property ignoreLaunchArgs is not allowed.