importScripts works in browser web EH but not in desktop web EH

[eleanorjboyd]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version:1.57.
• OS Version: Windows_NT x64 10.0.19043

Steps to Reproduce:

1. create a web extension
2. have the line importScripts("https://cdn.jsdelivr.net/pyodide/v0.17.0/full/pyodide.js"); in your extension.ts file (enable webworkers to use this command)
3. run extension on the desktop vscode
4. Error message: TypeError: Failed to execute 'importScripts' on 'WorkerGlobalScope': This document requires 'TrustedScriptURL' assignment.

The following error occurs when I try and run my web extension on the desktop vscode and it seems that the import scripts line pasted above that causes the error.

[aeschli]

I updated the title. importScripts works fine when in web extension host on a browser. The question is if this is intended to work.

[jrieken]

Yeah, there is two problems:

1. Web Worker extension loading stuff, esp via importScript. There are strict limitations that web worker extensions are bundled as single file, mostly for getting require('vscode') to work. So, for now I would not recommend to use importScript (or async-import) but for the future we need a better, web'ish solution.
2. Trusted types in the extension host worker. Currently trusted types are enforced in desktop and are optional for web, tho the plan is to have them on everywhere. It still leaves the question if we should enforce trusted types onto extensions - I feel not but also don't know how to disable them...

[joyceerhl]

It still leaves the question if we should enforce trusted types onto extensions - I feel not but also don't know how to disable them...

FWIW, extensions running in the web worker extension host should be able to spawn their own Workers which are not subject to the same CSP as the parent context: https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers#content_security_policy I think that means extensions should be able to work around the trusted types policy by creating a new Worker which loads whatever it wants and communicating with it using postmessage and onmessage.

[jrieken]

Yes - either run in a separate worker or bundle everything into a single JS file. That's what I would strongly recommend

[alexdima]

importScripts is really bad. It blocks the event loop of the extension host until the script is loaded. It is an oversight from our side that importScripts works in browser and we plan to block that. Our current recommendation is to bundle the entire extension in a single file or use multiple files by spawning a separate worker using new Worker. What is the use case of splitting up the web extension into multiple scripts? Do you load parts of the extension lazily, only when exercised? (i.e. is it a performance optimization)?

[jrieken]

Also discussed this with @aeschli yesterday and our thinking/plan is to prohibt importScripts from being called inside the worker extensions host. It is really bad for many reasons

• it blocks the event loop
• it cannot acquire the vscode-API object
• it will conflict with other extensions, e.g if another extension imports the same lib at a different version than you are in deep trouble

[joyceerhl]

Would extensions be able to continue to use importScripts inside new workers that they create?

Do you load parts of the extension lazily, only when exercised

Yes, for context, Eleanor and I are exploring use cases for Pyodide (Eleanor is investigating Pyodide for her internship, I'm doing a separate investigation out of personal interest). Pyodide is the CPython runtime, compiled to WASM and capable of running in a renderer or web worker. Pyodide can load and run Python packages as well, also compiled to WASM.

The problem is that it would be several hundred MB if we were to bundle and ship all the Python packages that users might conceivably want to import. For my specific use case, which is enabling users to run Python code in Jupyter notebooks via Pyodide in the browser web worker extension host, I would much rather lazy-load the JS/WASM for Python packages from a CDN than ship a large bundle upfront containing packages that the user may never need to use.

[jrieken]

Would extensions be able to continue to use importScripts inside new workers that they create?

Yeah, for web workers spawned by extensions we have no restrictions planned. Such workers are scoped to your extension, therefore less conflicting with other extensions or the extension host implementation. Esp. for something like Pyodide a dedicated worker is highly recommended

[alexdima]

Thank you for the extra information!

I also recommend in this case to create a new Worker(). So you can structure your extension by having a small piece that interacts with the vscode API and then that small piece would create a separate web worker that can be 10s of MB in size. You can then use postMessage to communicate between the extension and the web worker. I think you can also create a MessageChannel and pass one of the ports to the new worker.

[jrieken]

Closing this issue as I have pushed a commit that blocks importScript in the webworker extension host.

@aeschli you might now a place where to document this?

[jrieken]

To verify write a web extension that calls importScripts. Ensure that the call fails and that there is no workaround.

[aeschli]

I added it to the web extension wiki

[rchiodo]

I'm not sure how to write a web host extension. Is it documented somewhere/Or an example?

And assuming I write one, how do I test it?

[rchiodo]

@joyceerhl provided some steps internally.