Change:
<!DOCTYPE html> <html> <head> <del> <meta http-equiv="Content-Security-Policy" content="default-src 'none'; child-src 'self' data: blob:; script-src 'unsafe-eval' 'sha256-cb2sg39EJV8ABaSNFfWu/ou8o1xVXYK7jp90oZ9vpcg=' https:; connect-src https: wss:" /> </del> <ins> <meta http-equiv="Content-Security-Policy" content="default-src 'none'; child-src 'self' data: blob:; script-src 'self' 'unsafe-eval' 'sha256-cb2sg39EJV8ABaSNFfWu/ou8o1xVXYK7jp90oZ9vpcg=' https:; connect-src 'self' https: wss:" /> </ins> </head> <body> <script>

Discussion:
Issue Type: <bBug</bWhen attempting to launch a web-compatible extension with entry point under node VS Code host, following error is thrown:  When entry point is specified (in addition to ), the error is not thrown, but I need the extension to run in browser environment to access API (it uses .NET Blazor, which doesn't work with node's module). Here is the sample extension sources: VS Code version: Code 1.62.3 (, 2021-11-17T08:11:14.551Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (4)</summaryExtensionVersion ------ dotnetjs1.0.6 naninovel1.6.1 vscode-dotnet-runtime1.5.0 code-spell-checker2.0.13 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
And here is the published extension in question, in case you'd like to test it: It works fine in browser (via ), but throws the error in standalone VS Code.
VS Code uses as additional measure to protect from XSS. This is defined per document(-header). When running in web, e.g or , we isolate the web-worker running extensions in a separate iframe and that iframe doesn't inherit nor use trusted types. In contrast, when running in desktop we don't further isolate the web worker and therefore trusted types restrictions apply to extensions too
Thanks for the response! I've checked the linked article, but still not sure how to solve the issue. Should I add a trusted type policy before the extension is activated? If that's the case, what exactly should be inside the policy object for it to work in VS Code? It complains about evaluating a string as JavaScript code, so I guess it's about , but the extension doesn't use eval, nor does it use any of the DOM APIs, which are governed by the trusted types.
Yeah, I guess it's about , likely inside library or generated code. We don't allow that in our code and in the web_worker+desktop case that's a restriction that you are inheriting. I believe that's unwanted strictness from our side and something we should relax.
There are indeed 3 eval calls in the generated code, but they're not executed.

Just to make sure, I've replaced all of them with , but the same error is still thrown in VS Code.
Thanks for fixing this so quickly! Can you please clarify if there are still some limitations on using API in web extensions running in standalone? I can't connect to local websocket server () in standalone mode, while in browser it works fine.
Even locally we are strict and want (note the secure )
Ah, I see. Thought about it, but the fact that unsecure connection is working in browser and in standalone with .NET runtime gave me hope that you could allow it in this case as well. Thanks for the quick response!