support independent user-data-dir for extension debugging

[weinand]

I'm trying to decouple the "user-data-dir" used for extension debugging from the "usr-data-dir" of the "outer" VS Code instance. The goal is to allow the existing --user-data-dir command line flag in a launch config like this:

{
    "name": "Run Extension",
    "type": "extensionHost",
    "request": "launch",
    "args": [
        "--user-data-dir=/tmp/foobar",
        "--extensionDevelopmentPath=${workspaceFolder}"
    ],
    // ...
}

This does not work out of the box (see #126737).

After debugging this flow through the various processes, I ended up in WindowsMainService.openInBrowserWindow:

Here the command line argument correctly arrives in the configuration as user-data-dir, but then another property userDataDir is added based on the environmentMainService.userDataPath. See the two arrows in the debug hover.

After hacking/patching

vscode/src/vs/platform/windows/electron-main/windowsMainService.ts

Line 1240 in da7d76d

userDataDir: this.environmentMainService.userDataPath,

to:

userDataDir: options.cli?.['user-data-dir'] || this.environmentMainService.userDataPath,

the new VS Code instance got its own independent user data directory (the default dark theme is the proof):

Something like this seems to solve my problem...

What do you think?

[bpasero]

@weinand there is something here I do not really understand: the intent is to have a fully separate user-data-dir for the instance that is being debugged. As such, I would expect that somewhere there either needs to be code or there is already code that launches an instance like so:

code --user-data-dir <some folder to use as user data dir> ... more debug related args from the launch config

If that is the case, the userDataDir will be correct because it will properly be resolved as a normal startup by the user would.

Maybe I miss something but what we can not do is have the electron-main process be on the one user data dir and a window being on a different user data dir. Such a model is not supported by Electron. We need all processes to be on the same user data dir.

[bpasero]

A related question: I think we implement some of the extension host debugging features through IPC communication from the target window to the main process. I do not fully understand how that would work if the instance that is being debugged is fully separate, because then we do not share any IPC handle I think.

[weinand]

@bpasero yes, before the arrival of the web UI there was a piece of code in debug land that launched a VS Code instance (the debuggee) via the command line with:

code --extensionDevelopmentPath=/Users/weinand/foo --debugId=123456789 ...

But because that would not work in the web UI, we are now using an internal API (IExtensionHostDebugService.openExtensionDevelopmentHostWindow) to launch another window for both web UI or Electron.

Before going more into the details of this API, let's delve into your statement from above:

... but what we can not do is have the electron-main process be on the one user data dir and a window being on a different user data dir.

Assuming we would still launch the debuggee from within VS Code via the command line and now we would add a --user-data-dir flag like this:

code --user-data-dir <some folder to use as user data dir> 

I would expect that another electron-main process is created for the new VS Code instance (and by using VS Code's built-in "Process Explorer" I could confirm this). But this also means that debugging would never work, because IPC communication between two electron-main process is not supported.

With my prototype the new VS Code window (blue selected line) is still just another window under the same electron-main process, which explains why it can be debugged via IPC communication.

And the new window gets indeed different settings (but probably that only works because I'm lucky :-)

With these findings I see two ways how to proceed:

• instead of supporting an independent user-data-dir, just support independent user settings (does this makes sense at all? what other "unclean" state is inherited from VS Code?)
• support to debug an extension in another electron-main hierarchy by making the IPC communication work across different electron-mains.

I think the latter approach is cleaner and most likely easier to implement.

@bpasero I would like to explore this a bit more:
Passing a --user-data-dir command line flag should really create an independent electron-main hierarchy.

Today the entry point is openExtensionDevelopmentHostWindow in the main process where all the debug configuration properties are available in the same way as if they would come from the command line:

I'm not sure why the --user-data-dir command line flag does not result in a new electron-main hierarchy. Is there a better API entry point?

Debugging should transparently work because for js-debug extension debugging is just a form of remote debugging based on "attach". So it does not matter in which process hierarchy the debuggee lives.

The only problem will be the IPC mechanism...

[bpasero]

Yeah I agree with the sentiment that a true separate user-data-dir and thus separate electron-main process is ideal here to fully decouple the debugger from the target. I wonder, if we were to go down this route, would extension debugging be any different from debugging any other app? Maybe this would be a chance to get rid of all the extension debug specific code we have.

For example, for the longest time we do some tricks such as: If you press Cmd+Q in the debugee, we will close the window and not quit the app because otherwise all VSCode windows would terminate:

vscode/src/vs/platform/native/electron-main/nativeHostMainService.ts

Lines 730 to 735 in ee1655a

	// If the user selected to exit from an extension development host window, do not quit, but just
	// close the window unless this is the last window that is opened.
	const window = this.windowsMainService.getLastActiveWindow();
	if (window?.isExtensionDevelopmentHost && this.windowsMainService.getWindowCount() > 1 && window.win) {
	window.win.close();
	}

I'm not sure why the --user-data-dir command line flag does not result in a new electron-main hierarchy. Is there a better API entry point?

We do not offer any internal way of launching another instance of VSCode, so that call actually ends up here:

vscode/src/vs/platform/windows/electron-main/windowsMainService.ts

Line 1105 in ee1655a

openExtensionDevelopmentHostWindow(extensionDevelopmentPaths: string[], openConfig: IOpenConfiguration): ICodeWindow[] {

And it will open another window, independent from the config you pass in.

I think if we go down this route, I would expect that the debugger implements some code on the electron-main side (for example in ElectronExtensionHostDebugBroadcastChannel) to literally spawn another process with the right CLI arguments and then establish a debug connection via IPC.

Does that sounds reasonable?

[Elia-Sh]

TL;DR with and without: --user-data-dir, I was not able to isolate vscode execution for extension debugging.

Same here - osx, vscode version: 16.3
Was trying to test an extension which I'm developing in an "isolated" environment -
i.e not loading any settings/configuration from my system settings,

Expected that it would be straight forward via launch.json config,
but ended up scrolling through many bug reports, work arounds, official documentation pages, etc..

Hope that this will be addressed soon,
since testing vscode extensions with portable mode hacks, may be slightly counter productive.

[nya3jp]

Any update on this issue?

@vscode/test-electron 2.0.0+ sets --user-data-dir to run tests in a separate settings (#137678), which greatly improved test isolation. However tests launched from VSCode with F5 still access the current user data due to this issue.

[weinand]

Fixing the problem that the command line options --user-data-dir don't work in debug configurations is difficult and would result in large and high-risk code changes.

However, the reason for using the command line options in the first place, is the problem that extension debugging always uses the "main VS Code settings and extensions". So, it is not possible to debug an extension in a clean environment.

But with the recent work on settings profiles, "debugging an extension in a clean environment" is now in reach.

I will close this issue in favor of the new feature request #159572: "Support extension debugging in a clean environment"