Debugging webviews in VS Code

[connor4312]

Recently several people have asked about wanting to debug the contents webviews in VS Code.

I think is possible if the renderer is launched in debug mode; when debugging VS Code OSS I actually see CDP events for webviews coming down the pipe, e.g

If js-debug was able to attach to the renderer as well, then we should be able to attach to those webviews and debug them natively. There are two things that need to happen for this:

1. Currently the way extension host debugging works is that we launch VS Code via a custom launchVSCode DAP request, and then we get a subsequent attach request with a port set to the port of the extension host process. We could have a way to request the renderer to be launched in debug mode in the launchVSCode request, and have a rendererPort or something similar in the attach request.
2. We want to filter so that we don't attach to any extraneous webviews that might be show in the editor. Right now the CDP events I see for the webview are not very useful. The frame is untitled, doesn't provide URLs over the protocol. Eventually we see an "info changed" where it looks like HTML gets set in the document, but it's not something we can filter on easily. It would be helpful if we could fix the URLs, or perhaps title the webview so that we can determine where it's coming from. Here's a log of the CDP events I see today for the notebook renderer webview. cc @mjbvz

/cc @rebornix @eamodio @RMacfarlane as people who have asked for this :)

[isidorn]

For now unassigning myself, for features / changes on the VS Code side of course ping me and create corresponding issues. Thanks :)

[connor4312]

Some extra work will be needed on js-debug here. It's not "just" a target -- the target is for the outer webview, and we have an iframe inside of it. But the debugger for the webview is accessible on /json/list, we will need some extra logic that looks up the target on that page when a webview targets is created in the workbench.

However, this is asynchronous, and we want to be able to hit breakpoints early on in the code. I would recommend that we run something like this if we see extension host debugging is launched with renderer attachment:

let waitingForDebugger = true;
while (waitingForDebugger) { debugger; }

We can then hit that and set waitingForDebugger = false after we're ready to go. This busy-loop is not pretty, but is similar to what Node.js used to do waiting for an inspector (until 12.x when they made a change to not burn CPU).

[DonJayamanne]

Sorry for hijacking this issue to bring up something else, but if I'm not mistaken, this would/could allow one to attach a puppeteer/playwright client to these webviews and validate the UI, as part of a Smoke Test.

[connor4312]

That's already possible if you launch vs code like we do in the launch.json using --inspect, with some amount of wiring. But we could make it easier in test, perhaps.