Bugzilla

V8 has found that it's not web-compatible (at least for them, we haven't had a compatibility bug reported by Nightly/early Beta users) to expose the SharedArrayBuffer constructor when postMessage() throws. This is discussed in https://github.com/whatwg/html/issues/4732. Based on that discussion we've decided to hide (delete if you will) the constructor when cross-origin isolated is false.

Web developers can still get at the constructor through `new WebAssembly.Memory({ shared:true, initial:0, maximum:0 }).buffer.constructor`. The motivation here is web compatibility, not security.

https://github.com/web-platform-tests/wpt/issues/22358 links four PRs that update all tests in web-platform-tests that are impacted by this change. (Including a test to ensure globalThis.SharedArrayBuffer is indeed undefined across window and worker environments.)

In https://github.com/whatwg/html/pull/4734 commit https://github.com/whatwg/html/pull/4734/commits/b1ad28254eaed82c2342449198f3b38034abe4d3 I tried to spell out what this means standards-wise.

I don't have a concrete plan for how to do this code-wise. I think it would make the most sense that when `javascript.options.shared_memory` is true, the constructor is not there, but can be restored by `dom.postMessage.sharedArrayBuffer.withCOOP_COEP`. That way we can ship `javascript.options.shared_memory` to release in bug 1606624 while we sort out the remaining issues with COOP and COEP.

Tom, would you feel comfortable taking this or should we request the WebVM team to provide the necessary infrastructure?

V8 has found that it's not web-compatible (at least for them, we haven't had a compatibility bug reported by Nightly/early Beta users) to expose the SharedArrayBuffer constructor when postMessage() throws. This is discussed in https://github.com/whatwg/html/issues/4732. Based on that discussion we've decided to hide (delete if you will) the constructor when cross-origin isolated is false.

Web developers can still get at the constructor through `new WebAssembly.Memory({ shared:true, initial:0, maximum:0 }).buffer.constructor`. The motivation here is web compatibility, not security.

https://github.com/web-platform-tests/wpt/issues/22358 links four PRs that update all tests in web-platform-tests that are impacted by this change. (Including a test to ensure globalThis.SharedArrayBuffer is indeed undefined across window and worker environments.)

In https://github.com/whatwg/html/pull/4734 commit https://github.com/whatwg/html/pull/4734/commits/b1ad28254eaed82c2342449198f3b38034abe4d3 I tried to spell out what this means standards-wise.

I don't have a concrete plan for how to do this code-wise. I think it would make the most sense that when `javascript.options.shared_memory` is true, the constructor is not there, but can be restored by `dom.postMessage.sharedArrayBuffer.withCOOP_COEP`. That way we can ship `javascript.options.shared_memory` to release in bug 1606624 while we sort out the remaining issues with COOP and COEP.

Also, while it needs to be hidden from all web-exposed globals, i.e., Window, worker types, and worklet types, we should probably keep it exposed to chrome and jsshell.

Tom, would you feel comfortable taking this or should we request the WebVM team to provide the necessary infrastructure?