Closed lars-t-hansen closed 7 years ago
Sorry for not realizing the effect here--this seems like exactly why we shouldn't've done the change that I was pushing for. Reverting the change would be an acceptable path, but I like the idea to do the fix in HTML.
@littledan, fixing HTML to have a tighter spec for is-transferable is pretty clean, imo. Now that we've made the change in this proposal I'm not eager to revert it.
Does this issue still need to be open? Doesn't this encompass the same concern? https://codereview.chromium.org/2809253002/
@flagxor This is technically about the HTML spec. They are working on cleaning up the structured clone algorithm, https://github.com/whatwg/html/pull/2421 is a good place to start. Until that's been landed this bug should probably stay open.
(I don't see how the referenced bug is relevant here?)
This can be closed.
Make it so.
According to the HTML spec, if an object has an [[ArrayBufferData]] internal slot that is not detached then the object is transferable, see https://html.spec.whatwg.org/multipage/infrastructure.html#istransferable.
Recently we made the change that we use [[ArrayBufferData]] even for a Shared Data Block, and this slot cannot become detached. This was a much-desired change. But roughly at the same time we decided that postMessage() should not allow for a SharedArrayBuffer in the transfer list, and this is now encoded in the SAB companion spec for DOM, see https://tc39.github.io/ecmascript_sharedmem/dom_shmem.html.
Clearly these decisions are not quite compatible. The fix is probably to hack up the HTML spec to discriminate better. This needs to be noted with greater specificity in section 1.5 of our DOM companion spec.