Detecting launched web servers and/or browser instances

[lostintangent]

The Live Share extension in Visual Studio Code already allows sharing debug sessions between collaborators when the host runs a launch configuration, and manually forwarding application ports, however, we would love to be able to support the following capabilities as well, to improve/simplify collaborative-debugging:

1. Automatically detecting whether the debug adapter launched a new web server (e.g. ASP.NET Core, Node.js), and if so, which port it is listening to. This would allow us to transparently forward that port from the host's machine to the guest's machine, so that the guest could access/interact with the web app/API, without the hosting user needing to explicitly perform the port forward themselves (via a command in the command palette).

2. Automatically detecting whether the debug adapter launched a new web browser (e.g. ASP.NET Core, Chrome Debugger), and if so, which URL it navigated to. This would allow us to launch a browser on the guest's machine as well, so that all participants within a collaboration session could be viewing the same app, without needing to manually discover/navigate to it themselves.

We currently support both of these experiences from Visual Studio thanks to the project system, but it would be great to have some kind of general-purpose mechanism in the debug protocol (two new event types that adapters could fire?) to allow debug adapters to announce this metadata.

[weinand]

@lostintangent I do not quite understand how and when a debug adapter would send those events?

I'm not aware of a standard way of announcing a server port from within a running node.js program.
Some might do a console.log(...) but the output from this is not available to the DA if VS Code's integrated terminal (or an external terminal) is used.

However, there is a convention to specify the web server's port via an environment variable. In VS Code this would be done by setting like this:

{
    "type": "node",
    "request": "launch",
    "name": "Launch Express app",
    "program": "${workspaceRoot}/www",
    "env": {
        "PORT": "3000"
    }
}

You could use this information to configure a port forwarder.

@roblourens what's your perspective?

[lostintangent]

For Node.js, I totally agree: I’m not sure how the debug adapter would know this information, without using some kind of convention to infer or detect it. That said, I couldn’t help but wonder whether it would be better for such conventions to be built into debug adapters (if they know it), as opposed to extensions (like Live Share), which could potentially couple themselves to app platform-specific behavior unnecessarily, and also duplicate logic.

Besides the Node.js adapter, it seems like the C# extension knows this (I believe it scrapes the URL from the debuggee process’ stdout?), and the Chrome debugger would know the URL it launched based on its own (unique?) config. Maybe those two are the exception, and this functionality isn’t general enough to warrant inclusion into the debug protocol, but I wanted to optimistically throw it out there for discussion :)

[roblourens]

(1) is hard to do in general. To make it generic, the adapter could report which ports are opened by the spawned process, but we don't know how long it will take a server to open its port, or it could be spawning child processes which are the real servers, etc.

(2) is easy, the adapter starts the browser and passes it the url from the config. For an attach config, it could report the url of the attached tab.

[auchenberg]

Adding my reply I've send over email to @lostintangent:

At this point in time we don't have a mechanism in the DAPs or in the protocol that would allow a DAP to communicate back the ports of running processes or backchannel the url. So if the DOTNETCore debug adaptor is launching a browser, it's probably doing it directly from it's own Node process via an NPM package.

For Node we have an ongoing challenge to detect which Node process that has been spawned, and which ports that are used, as a process can start multiple servers, use multiple ports etc. Maybe it's a HTTP server, WebSocket, etc. We don't know.

If a process is launched from the integrated terminal in VS Code, we can detect it, as it will be a child process to VS Code, and that way we can find out which port it's using etc, but it won't allow us to construct a specific URL.

The best pointer is probably to look at the launch.json debug configs when debugging has been activated, and if fx the Chrome debugger is used, the "url" property could be use for LiveShare.

[weinand]

Here are VS Code's possible terminal options for running the debuggee:

• Debug Console: DA (debug adapter) receives the stdout/stderr/console data from the debuggee and can easily scrape the output for server ports etc.
• Integrated Terminal: receives stdout/stderr/console data from the debuggee but the DA has no access to the Integrated Terminal because it is managed completely by VS Code. So the output scraping could only be done in VS Code itself, but not in the DA.
• External Terminal: receives stdout/stderr/console data from the debuggee but typically an External Terminal is not a child process of VS Code. So it is impossible to do any output scraping.

So only the first option could use the DAP event.

I agree with @auchenberg that analysing the launch configuration is probably the most promising approach (and the Live Share extension already has access to it).

[lostintangent]

@weinand @auchenberg Makes sense. Thanks so much for explaining that! In practice, do we know how prevalent it is for launch configurations to include the server port or URL (e.g. either as an env var or a debug adapter-specific setting?).