Support [AllowShared]
Categories
(Core :: DOM: Bindings (WebIDL), enhancement, P2)
Tracking
()
People
(Reporter: saschanaz, Assigned: edgar)
References
(Blocks 3 open bugs)
Details
Attachments
(5 files, 1 obsolete file)
[AllowShared]
allows IDL operations to receive SharedArrayBuffer-backed buffer source types, and thus required for SharedArrayBuffer uses.
Comment 1•5 years ago
|
||
In a way this is a duplicate of bug 1231687, but it's also much clearer...
Updated•5 years ago
|
Comment 3•5 years ago
|
||
Edgar, is this something you could take this on? (The priority comes from the duplicate and because this is important for eventually shipping SharedArrayBuffer
support.)
Assignee | ||
Comment 4•5 years ago
|
||
Yes, I could take this one.
Assignee | ||
Comment 5•5 years ago
|
||
Comment 6•5 years ago
|
||
Edgar, we should probably also clean up some of the code of https://hg.mozilla.org/mozilla-central/rev/91fe35e7df1fa3124c266c249ad0907320dfd956. E.g., Crypto::GetRandomValues will now be checked at the IDL layer so there's no need for it to throw inline, right? Similarly, the TypedArray bindings setup described there is no longer needed as we get safety from the IDL layer so we know if we can be dealing with shared beyond that and there's no need for two explicit APIs. (Edit: I guess an exception here is APIs that use any
, such as postMessage()
, but we need to check those either way as treating a SharedArrayBuffer as an empty buffer is wrong too.)
Assignee | ||
Comment 7•5 years ago
|
||
(In reply to Anne (:annevk) from comment #6)
Edgar, we should probably also clean up some of the code of https://hg.mozilla.org/mozilla-central/rev/91fe35e7df1fa3124c266c249ad0907320dfd956. E.g., Crypto::GetRandomValues will now be checked at the IDL layer so there's no need for it to throw inline, right?
Yes, we could drop those inline checks in this bug, I would think.
Similarly, the TypedArray bindings setup described there is no longer needed as we get safety from the IDL layer so we know if we can be dealing with shared beyond that and there's no need for two explicit APIs. (Edit: I guess an exception here is APIs that use
any
, such aspostMessage()
, but we need to check those either way as treating a SharedArrayBuffer as an empty buffer is wrong too.)
And I plan to do TypedArray clean up in a follow-up bug.
Comment 8•5 years ago
|
||
(Removing "resab" as blocker to make that bug's immediate dependencies less cluttered. This still remains important for shipping SharedArrayBuffer (without postMessage() support) to release in 75.)
Assignee | ||
Comment 9•5 years ago
|
||
There is no SharedArrayBuffer type defined in WebIDL spec.
Assignee | ||
Comment 10•5 years ago
|
||
We need this for upcoming change which supports having [AllowShared] on
ArrayBuffer type in WebIDL.
Assignee | ||
Comment 11•5 years ago
|
||
Assignee | ||
Comment 12•5 years ago
|
||
Assignee | ||
Comment 13•5 years ago
|
||
Now we support [AllowShared] in WebIDL, we don't need to manually check shareness
and throw exception if API don't accept SharedArrayBuffer, the binding will handle
it.
Assignee | ||
Comment 14•5 years ago
|
||
There's no need for two explicit APIs as we get safety from the IDL layer. And
treating a SharedArrayBuffer as an empty buffer is wrong too.
Assignee | ||
Comment 15•5 years ago
|
||
Assignee | ||
Comment 16•5 years ago
|
||
Assignee | ||
Comment 17•5 years ago
|
||
Assignee | ||
Comment 18•5 years ago
|
||
Updated•5 years ago
|
Updated•5 years ago
|
Comment 19•5 years ago
|
||
Comment 20•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/76604cb38aad
https://hg.mozilla.org/mozilla-central/rev/81b22b1796a6
https://hg.mozilla.org/mozilla-central/rev/285f272135f4
https://hg.mozilla.org/mozilla-central/rev/8cf423865978
https://hg.mozilla.org/mozilla-central/rev/f2b77060cc80
Updated•5 years ago
|
Description
•