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.