Towards "cross origin isolation"

[isidorn]

We have made changes to enable cross origin isolation for VS Code desktop and vscode.dev. This will enable new powerful features like shared array buffers. VS Code itself but also for extensions and webviews will benefit from this.

Cross origin isolation is currently behind a feature flag and enabling it might have unwanted effects on extensions and webviews that load resources from the internet. You can read more about this here: https://web.dev/why-coop-coep/. We would like to hear your feedback early. To try this

• run VS Code desktop with the --enable-coi-flag, e.g code --enable-coi, or
• in web append the vscode-coi-query

To check that cross origin isolation is enabled use the Application-tab of devtools or check the value of the crossOriginIsolated global variable.

[lgrammel]

I've just tried this out and my extension breaks at various places (e.g. images loaded from the web in the walkthrough). When are you planning to enable this for all users?

[isidorn]

Thanks for trying it out.
@jrieken would know the exact plan.

[jrieken]

images loaded from the web in the walkthrough

Where do you load these images from? Do you have control over that server (so that the CORP header can be set) or can you bundle them into your extension?

[lgrammel]

Yes, I can set the right headers up on the server, if that's a reasonable fix. I want to prevent increasing the extension download size, so bundling would only be my second choice. Will cross origin isolation be enabled in the next vscode version by default? (trying to understand until when I need to have this fixed)

[jrieken]

be enabled in the next vscode version by default?

We didn't decide on that yet but I'd say likely no. We want to give enough time for folks to prepare for this

[matthewjamesadam]

Hi @isidorn, thanks for the heads-up on this issue.

• Our extension contains webviews that display images that are from third-party services and cannot be packaged with the extension (along the lines of giphy images or user avatars). This works currently without COI enabled, but once it is enabled these images do not load (the error is Failed to load resource: net::ERR_BLOCKED_BY_RESPONSE.NotSameOriginAfterDefaultedToSameOriginByCoep). We have defined a CSP that does allow images from the domain in question, but it doesn't seem to help.
• Our webviews are making fetch requests to some third-parties (telemetry and error handlers like logz.io, sentry), and these are not being blocked. I found it hard to tell from reading the documentation if this is expected or not.
• Just as a side note, enabling COI breaks images in the extensions sidebar:

[jrieken]

This works currently without COI enabled, but once it is enabled these images do not load (the error is Failed to load resource: net::ERR_BLOCKED_BY_RESPONSE.NotSameOriginAfterDefaultedToSameOriginByCoep). We have defined a CSP that does allow images from the domain in question, but it doesn't seem to help.

The server that provides the resources needs to set the CORP-header (https://web.dev/why-coop-coep/#corp) to allow its resources to be embedded here

Our webviews are making fetch requests to some third-parties

That's expected - this is only about resources but requests

Just as a side note, enabling COI breaks images in the extensions sidebar

Yeah, our marketplace (and githubraw) doesn't set the CORP header yet

[matthewjamesadam]

Thanks for the response @jrieken

This works currently without COI enabled, but once it is enabled these images do not load (the error is Failed to load resource: net::ERR_BLOCKED_BY_RESPONSE.NotSameOriginAfterDefaultedToSameOriginByCoep). We have defined a CSP that does allow images from the domain in question, but it doesn't seem to help.

The server that provides the resources needs to set the CORP-header (https://web.dev/why-coop-coep/#corp) to allow its resources to be embedded here

Is there any other workaround or advice for this scenario? I suppose our webviews could manually fetch and populate img elements as a last resort.

[PEZ]

My extension, Calva, downloads a lot of things from the net. All that seems to work with COI enabled. I sort of expected it too, because this seems to be about resources loaded in other ways. Or the sites that we download from might have their cross origin headers in order?

Can you give some examples on where this settings would make a difference? And maybe publish some test resources that will work and some that wont. That would help me understand if I should be worried about this change or not. 😄

[hugocaillard]

Thanks for giving updates and insights about this.
I'm currently working on a extension that embeds Rust code compiled to WASM and relies on Atomics wait/notify, and thus on shared array buffers.
It could also benefits from shared array buffer in many other ways but I found workarounds until now.
Do you have a idea of when it will be enabled by default?
Thanks

[aykevl]

Is there any plan for enabling this feature? I would really like to use SharedArrayBuffer inside a Webview to communicate between web workers that are otherwise blocking. I can get my extension to work when I pass --enable-coi but of course that's not something I can ask users of the extension.

[itsdouges]

Hi! With WebGL / WebGPU becoming more main stream, as well as my development with Triplex for VS Code, I have some users that use Shared Array Buffers. Unfortunately currently it doesn't work easily in VS Code, but fine in the standalone app.

Two questions:

• Is there any roadmap that speaks to enabling COI for all users by default?
• Is there a config option to have VS Code always run with --enable-coi for users?