SharedWorker does not provide SharedArrayBuffer
Categories
(Core :: DOM: Workers, defect, P3)
Tracking
()
People
(Reporter: sberg.fun, Assigned: cwiiis, NeedInfo)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
Attachments
(2 files)
Steps to reproduce:
As originally asked about at https://discourse.mozilla.org/t/support-for-sharedarraybuffer-in-sharedworker/145358 "Support for SharedArrayBuffer in SharedWorker?": When serving content with Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp, a SharedWorker does not provide SharedArrayBuffer, and while it allows to create a shared WebAssembly.Memory, that is effectively useless, as that memory object cannot be passed over a channel.
Consider test.js
console.log('test 1:');
console.assert(typeof SharedArrayBuffer !== 'undefined');
console.log('test 2:');
const mem = new WebAssembly.Memory({initial: 1, maximum: 1, shared: true});
const ch = new MessageChannel();
try {
ch.port1.postMessage(mem);
} catch (e) {
console.error(e);
}
console.log('done');
and the two scenarios window.html
<html>
<body>
<script type="text/javascript" src="test.js"></script>
</body>
</html>
and sharedworker.html
<html>
<body>
<script type="text/javascript">
new SharedWorker('test.js');
</script>
</body>
</html>
Actual results:
While window.html succeeds, sharedworker.html fails with
test 1: test.js:1:9
Assertion failed: test.js:2:9
test 2: test.js:3:9
Error: undefined test.js:9:10
<anonymous> http://localhost:6931/test.js:9
done test.js:11:9
Expected results:
When setting dom.postMessage.sharedArrayBuffer.bypassCOOP_COEP.insecure.enabled to true (which can only be done in Nightly), sharedworker.html succeeds as well with
test 1: test.js:1:9
test 2: test.js:3:9
done test.js:11:9
|
||
Comment 1•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::JavaScript: WebAssembly' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Updated•11 months ago
|
|
||
Updated•11 months ago
|
|
||
Updated•11 months ago
|
|
|
||
Comment 2•11 months ago
|
||
The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit BugBot documentation.
|
||
Updated•11 months ago
|
|
||
Comment 3•7 months ago
|
||
Chromium issue: https://issues.chromium.org/issues/386633375
This seems to be a problem in Chrome as well.
|
Assignee | |
Comment 4•5 months ago
|
||
SharedWorkers now inherit the creating window's COOP via RemoteWorkerData,
enabling crossOriginIsolated and SharedArrayBuffer access when the creator
has appropriate COOP+COEP headers set.
|
||
Updated•5 months ago
|
|
|
Assignee | |
Comment 5•5 months ago
|
||
This isn't my area, so I'm hoping reviewers will be able to guide me somewhat, but this seemed like an ok thing to do to enable this functionality and Chrome developers seem to agree: https://issues.chromium.org/issues/442483666#comment11 - but I don't know if there are implementation-specific security issues to consider.
|
|
||
Comment 6•5 months ago
|
||
Noting that there is a lot of context in bug 1613912 (that I need to re-digest), needinfo on myself in regards to https://phabricator.services.mozilla.com/D288155#10000612.
|
|
Assignee | |
Comment 7•3 months ago
|
||
Without this, two same-origin top-level tabs that are both
cross-origin-isolated end up in different BrowsingContextGroups. The
HTML spec keys cross-origin-isolated agent clusters by
(origin, COI-mode) and lets them span browsing context groups; Firefox
did not. The SharedWorker COOP propagation in the parent commit made
this observable for the first time: a SharedWorker in a webCOOP+COEP
process can now ship a SharedArrayBuffer-backed view, but
postMessage'ing one to a second connecting window in a different tab
didn't work.
This patch fixes DocGroup::mAgentClusterId derivation only for the
cross-origin-isolated case: when the BrowsingContextGroup is COI we
fold the document's origin into a deterministic v5 (name-based, SHA-1)
UUID, so all same-origin COI DocGroups produce the same agent cluster
ID regardless of which BCG they belong to. The non-COI path keeps the
existing nsID::GenerateUUID() behaviour, so nothing about non-isolated
loads changes.
Description
•