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.

[DonJayamanne]

Oh I need to try that, I didn't know it was possible to inspect webviews in this manner. Thanks

[connor4312]

Looking into this more. Currently when we debug an extension host, we simply window.open

vscode/src/vs/code/browser/workbench/workbench.ts

Lines 216 to 233 in 2b166d8

	async open(workspace: IWorkspace, options?: { reuse?: boolean, payload?: object }): Promise<void> {
	if (options?.reuse && !options.payload && this.isSame(this.workspace, workspace)) {
	return; // return early if workspace and environment is not changing and we are reusing window
	}
	const targetHref = this.createTargetUrl(workspace, options);
	if (targetHref) {
	if (options?.reuse) {
	window.location.href = targetHref;
	} else {
	if (isStandalone) {
	window.open(targetHref, '_blank', 'toolbar=no'); // ensures to open another 'standalone' window!
	} else {
	window.open(targetHref);
	}
	}
	}
	}

This will re-use the same renderer. I think we will either need to:

• Force the current renderer into debug mode -- electron has APIs for this, or
• Launch a totally separate instance of vscode with the renderer in debug mode

This will, of course, not work when developing in the browser, since we can't force a running browser into debug mode nor launch a new one from the web

[connor4312]

Turns out there one piece of API missing that Electron does not expose to us. I have opened an issue for this here... extremely annoying electron/electron#24168

I may be able to hack around this if I only attach to a single iframe at once (though I would still be unable to distinguish between the iframe's messages and those of the root session). That involves some deeper changes in the debug adapter. We will see what they say for this.