Allow running remote extensions in the web worker extension host

[thegecko]

Does this issue occur when all extensions are disabled?: N/A

• VS Code Version: 1.63.2
• OS Version: Web

Issue:

There seems to be a mismatch in details about how to run an extension in a specified extension host versus reality.

In my situation I have an extension which I'd like to run in the following way:

• When run in VS Code Desktop or VS Code with remote, I'd like the extension to execute in the local extension host.
• When run in VS Code Web (Codespaces or *.dev), I'd like the extension to execute in the web extension host.

Looking at the information outlined here:

https://code.visualstudio.com/api/advanced-topics/extension-host

I believe I need to describe this extension with extensionKind: [ui] to request it is run in the local extension host. The details for this extensionKind explicitly outlines:

In the case of VS Code for the Web with Codespaces, where no local extension host is available, such an extension can not load, unless it is *also* a web extension. It will then be loaded in the web extension host

Which leads me to believe I can also describe this as a web extension as outlined here:

https://code.visualstudio.com/api/extension-guides/web-extensions

Which states:

Extensions can have both browser and main entry points in order to run in browser and in Node.js runtimes.

My extension has both a main and a browser entry point, as this seems to be supported in the link above and I would expect the browser entrypoint to be used in the web extension host and the main entrypoint anywhere else.

When running the extension on the desktop (normally or using remote), this seems to work as expected, however the web flavours of VS Code fail to load the extension with the error:

This extension is disabled because it is not supported in Visual Studio Code for the Web

Question

Before I delve into the (rather complicated) loading code, I'd like to understand the intent here and whether the expectation is that an extension can be setup to run in this way.

[thegecko]

Further details on this.

I tested the vscode-css-fomatter example project as mentioned in the docs.

Although it has a browser entrypoint when running in codespaces, it executes in the remote extension host using the main entrypoint.

[alexdima]

@thegecko The web worker extension host has more limitations compared to the nodejs extension host. That's why we will mostly prefer to run an extension on the nodejs extension host if a nodejs extension host is available.

---

In the case of vscode-css-formatter, it doesn't have an extensionKind, but it has a main and a browser entry point. In code, we will deduce that as:

• ['workspace', 'web'] when running on web
• ['workspace'] when running on desktop
  This means:
• on VS Code Desktop, it will run in the (only) nodejs extension host
• on VS Code Desktop + a remote, it will run on the remote nodejs extension host
• on VS Code Web + a server (e.g. Codespace), it will run on the remote nodejs extension host
• on VS Code Web without a server (e.g. code.dev), it will run on the web worker extension host.

---

In case an extension would use "extensionKind": ["ui"] and it would have both a main and a browser entry point, we would enrich that to ['ui', 'web']. This means:

• on VS Code Desktop, it will run in the (only) nodejs extension host
• on VS Code Desktop + a remote, it will run on the local nodejs extension host
• on VS Code Web + a server (e.g. Codespace), it will run on the web worker extension host
• on VS Code Web without a server (e.g. code.dev), it will run on the web worker extension host.

---

That being said, this is pretty complex and has a lot of corner cases, like for example if an extension somehow got installed remotely instead of locally, etc.

[thegecko]

Thanks for the feedback @alexdima

In case an extension would use "extensionKind": ["ui"] and it would have both a main and a browser entry point, we would enrich that to ['ui', 'web']. This means:

on VS Code Desktop, it will run in the (only) nodejs extension host
on VS Code Desktop + a remote, it will run on the local nodejs extension host
on VS Code Web + a server (e.g. Codespace), it will run on the web worker extension host
on VS Code Web without a server (e.g. code.dev), it will run on the web worker extension host.

This is exactly what I want to happen and I'm glad this is the intent. However this setup yields the following error in Codespaces:

This extension is disabled because it is not supported in Visual Studio Code for the Web

I'll create a small extension to repro the issue...

[thegecko]

Simple VSCode extension which replicates this issue:

https://github.com/thegecko/vscode-extension

This extension has both main and browser entrypoints as well as a ui extensionKind.

It fails to load in codespaces.

[alexdima]

@thegecko How do you load this extension? We might be running into one of those ugly corner cases where an extension needs to be published to the marketplace and installed such that it gets "installed" on the browser side. i.e. isInstalledLocally might be false here.

[thegecko]

Erk.

How do you load this extension?

I upload it to the workspace and install it from there :/

How can I test this without publishing it?

[alexdima]

@sandy081 How can we simulate a browser "installed" extension? i.e. I think it would need to be returned from here --

vscode/src/vs/workbench/services/extensions/common/abstractExtensionService.ts

Lines 1002 to 1004 in a514979

	this._webExtensionsScannerService.scanSystemExtensions().then(extensions => system.push(...extensions.map(e => toExtensionDescription(e)))),
	this._webExtensionsScannerService.scanUserExtensions().then(extensions => user.push(...extensions.map(e => toExtensionDescription(e)))),
	this._webExtensionsScannerService.scanExtensionsUnderDevelopment().then(extensions => development.push(...extensions.map(e => toExtensionDescription(e, true))))

[sandy081]

You can side load a browser installed extension using the command - Developer: Install Web Extension and I also think @aeschli knows and documented how to develop & test a web extension so that it can run on web worker extension host, for eg., it will be returned by line 1004. @aeschli Can you please share the link to the doc?

[thegecko]

You can side load a browser installed extension using the command - Developer: Install Web Extension

Thanks, glad to see this is possible but currently trying to work out how to make it work.

Using a https target URI (vsix or unpacked) hits CORS violations and using a local URI path fails to locate the package.json.

@aeschli Should this URI be fully qualified to the root of the running container or support variables?

[thegecko]

Following these steps:

https://code.visualstudio.com/api/extension-guides/web-extensions#test-your-web-extension-in-on-vscode.dev

I was able to prove the expected behaviour as working in https://vscode.dev

Is there a way to test this in codespaces or can I assume it will just work the same and not use the other extension hosts?

[aeschli]

@thegecko With Codespaces, you mean the Codespaces Web UI?

Out of the VS Code sources you can emulate this by running

./scripts/code-server.sh --install-extension ../vscode-extension/vscode-extension-1.0.0.vsix --start-server --launch

(more documentation is on the way)

[aeschli]

IMO the extension should be able to run in the Web UI of a code server.

Maybe the bug is here:

vscode/src/vs/workbench/services/extensionManagement/browser/extensionEnablementService.ts

Line 356 in 5c6672c

if (this.extensionManagementServerService.webExtensionManagementServer) {

Do we also need a server === this.extensionManagementServerService.remoteExtensionManagementServer alternative?

[sandy081]

@aeschli This is not a bug and it is working as designed. Above code is to show the state of the extension and it resonates with how extensions are enabled in different extension hosts. It seems this extension cannot run in any of our extension hosts because:

• this could be a pure browser extension and installed on the server

In this case neither remote extension host nor web worker extension host can run this extension because former is missing main entry point and the latter does not find this extension. We do not generally run extensions across extension hosts - @alexdima please correct me if I am wrong.

[thegecko]

Thanks for the ongoing feedback.

@thegecko With Codespaces, you mean the Codespaces Web UI?

Yeah, starting a codespace and getting the extension to install and run in the web extensionHost.

This is not a bug and it is working as designed

I'm confused, the example I shared mimics the setup outlined above by @alexdima which should result in extensionHost: ['ui', 'web'] and therefore run as described above.

In this case neither remote extension host nor web worker extension host can run this extension because former is missing main entry point and the latter does not find this extension

The example has main and browser entry points

We do not generally run extensions across extension hosts

This would be a shame as the only workaround I have is to distribute multiple extensions which only differ in how extensionKind is resolved (and have to manage how to ask a user to install the right one).

[alexdima]

We've met today and agreed that this is a bug. However, it is very late to fix this for January.

To align with the documentation at https://code.visualstudio.com/api/advanced-topics/extension-host

We agree:

• remove isInstalledLocally from

  vscode/src/vs/workbench/services/extensions/browser/extensionService.ts

  Line 159 in b8178e3

  if (extensionKind === 'web' && isInstalledLocally) {

• the if statement needs to be tweaked at

  vscode/src/vs/workbench/services/extensionManagement/browser/extensionEnablementService.ts

  Lines 357 to 359 in b8178e3

  	if (server === this.extensionManagementServerService.webExtensionManagementServer) {
  	return false;
  	}

[thegecko]

We've met today and agreed that this is a bug. However, it is very late to fix this for January.

Thanks for persisting with this and glad there is agreement. I understand this fix is too late for the current release :)

Let me know if I can help in any way.

[alexdima]

@sandy081 I pushed the change in the IExtensionService.

[sandy081]

@alexdima Pushed changes in ExtensionEnablementService - In Web, an extension with browser endpoint is enabled when installed in remote. But I think IExtensionService does not support it completely. I still see extension is not loaded into web worker extension host. It seems the extension is not loaded here

vscode/src/vs/workbench/services/extensions/browser/extensionService.ts

Line 202 in 1dd058d

localExtensions = filterByRunningLocation(localExtensions, this._runningLocation, ExtensionRunningLocation.LocalWebWorker);

[alexdima]

To verify, please try out the following:

• download the vsix of vim from https://marketplace.visualstudio.com/items?itemName=vscodevim.vim
• use the command ./scripts/code-server.sh --install-extension ./vim-extension-1.0.0.vsix --start-server --launch
• open the web ui and see that the vim extension executes in the web worker extension host (check in Running Extensions).
• in the extension view, this extension is shown as installed in the remote, but the extension is still enabled.

[alexdima]

I had to disable this again due to integration test failures. We'll try again via a PR.