window.SharedArrayBuffer will disappear in webviews soon

[Tyriar]

FYI In Chrome 91, SAB will no longer exist on window unless cross origin isolation is enabled: https://developer.chrome.com/blog/enabling-shared-array-buffer/. This change may cause bugs in extensions that use SharedArrayBuffer with falling back to ArrayBuffer.

In order to eventually support SAB for web workers in webviews (#87282) this will probably need to be an opt-in setting in WebviewOptions.

[Tyriar]

FYI @deepak1556, this should block the Electron update when it goes to m91 since I believe accessing SharedBufferArray will cause an exception, likely breaking many webviews using libs.

[deepak1556]

I have to look into what needs to be done for cross-origin isolation with iframe based webviews and the workbench. But given our workbench will soon be on a custom protocol, this should be possible. I will update with more info in May debt week.

[Tyriar]

@mjbvz I've started hitting this in codespaces on Edge, some things just don't work anymore as there's no fallback yet if SAB isn't there. This isn't an easy thing to do as well since the workers Luna Paint use are built around SAB

687.js:1 Uncaught (in promise) ReferenceError: SharedArrayBuffer is not defined
    at p._startMove (687.js:1)
    at pointerDown (687.js:1)
    at vscode.main.js:1
    at n.fire (vscode.main.js:1)
    at HTMLDivElement.<anonymous> (vscode.main.js:1)

[mjbvz]

@Tyriar For codespaces, the codespaces team will need to change the code spaces host page, correct? Not sure if that will cause issues for other webview functionality though

[Tyriar]

Yeah you're right, reporting to them.

[corwin-of-amber]

This seems to be a problem in renderer processes too. Or am I missing something? Is there a straightforward way to set the COOP/COEP headers in the renderer process when it uses a file:// schema?

[deepak1556]

@corwin-of-amber you cannot set those headers for file protocol but if you were to use a custom standard protocol https://github.com/electron/electron/blob/main/docs/api/protocol.md#protocolregisterschemesasprivilegedcustomschemes then you will be able to provide those headers.

[corwin-of-amber]

Thanks @deepak1556 ! Looks a bit hefty just to get SharedArrayBuffer but there seem to be other benefits too.

[PaulOrlov]

The SharedArrayBuffer does not work ("SharedArrayBuffer is not defined") in the renderer already for Electron 14

[Tyriar]

FWIW I made Luna Paint resilient to this which means it works again in Codespaces. Since workers aren't supported in webviews anyway yet (#87282) this should be able to be worked around in the extension with:

if (!('SharedArrayBuffer' in window)) {
  (window as any).SharedArrayBuffer = ArrayBuffer;
}

It would be nice to fix this in Electron 14 as it's inconvenient to add the above workaround when we could build it into core, and technically a breaking change.

[deepak1556]

This requires a bit of replicating the work done for the web application.

@mjbvz what are the COOP and COEP headers set for webview on the web ? Also, is this behind an opt-in setting on the web ?

Also can we limit this to only for web worker based extensions ? This is to make sure we don't allow passing these shared buffers to other privileged processes when the renderer is sandboxed.

[Tyriar]

Also can we limit this to only for web worker based extensions ?

@deepak1556 do you mean webview based extensions?

This is to make sure we don't allow passing these shared buffers to other privileged processes when the renderer is sandboxed.

If it would be possible to pass a SAB from a webview to the extension host in the desktop case that would be amazing, if so and it's a security concern, perhaps we should allow opting into this in the package.json and warning on extension install or something? The win that this would give would be huge:

• No more transferring many MBs of image data back and forth which locks up the webview UI thread
• I could enable hot exit/backup for most images (unless they're enormous) as transferring the data would be instant
• Coupled with worker support, encoding could be done there which would let me add a responsive loading bar to the webview and the final save transfer would be super fast

[601355640]

import { session } from 'electron'
session.defaultSession.webRequest.onHeadersReceived((details, callback) => {
callback({
responseHeaders: {
...details.responseHeaders,
'Cross-Origin-Opener-Policy': 'same-origin',
'Cross-Origin-Embedder-Policy': 'require-corp',
}
})
})

[7ombie]

Can we share a SharedArrayBuffer between the renderer context and the node context?

[jrieken]

This is now implemented but because of potential breakage must be explicitly enabled with the --enable-coi command line flag

[safasofuoglu]

@jrieken could you clarify whether your implementation covers @Tyriar 's use case:

If it would be possible to pass a SAB from a webview to the extension host

And if not, whether it's possible at all through further work?

[mmis1000]

Is that even physically possible if extension host and webview can live in different machine? In some case like ssh remote, extension may lives in remote host but webview is always on local.

[jrieken]

It depends on the what extension host you are dealing with: There is the local nodejs-based extension hot, there is remote extension host (ssh, wsl, docker, etc), and there is the local webworker-based extension host. I haven't tested any of this but the former two aren't supported (different processes/machines) but the latter should be possible (e.g web worker to web view)