Before P1, GetCurrentThreadSerialEventTarget would have always returned the same data as NS_GetCurrentThread, making the comment incorrect Now it will properly return the running TaskQueue if any.
This change of name more clearly exposes what they are doing, as we aren't always dealing with threads directly; but a nsISerialEventTarget
Differential Revision: https://phabricator.services.mozilla.com/D80354
When structured clone reads a SAB and creates a new SAB object, or
when it serializes a SAB onto a channel, call a callback that lets the
embedder know. The embedder can then adjust its policy. Concretely,
we want to allow the browser to serialize threads in a process that
uses JS shared memory.
Note, for WebAssembly.Memory, reading and writing are delegated to the
cloning operations for SAB, so no special handling is needed.
Differential Revision: https://phabricator.services.mozilla.com/D61455
The idea is to propagate error messages defined in js.msg to
StructuredCloneHolder and throw it with a data clone error later. So that
developers can still understand the reason why serialization/deserialization
fails and we don't need to implement two similar set of error messages on JS and
DOM sides.
Note that this patch gave up the original idea (report error message to
console), but developers can stil get the error message by catching the
exception.
Differential Revision: https://phabricator.services.mozilla.com/D62260
When structured clone reads a SAB and creates a new SAB object, or
when it serializes a SAB onto a channel, call a callback that lets the
embedder know. The embedder can then adjust its policy. Concretely,
we want to allow the browser to serialize threads in a process that
uses JS shared memory.
Note, for WebAssembly.Memory, reading and writing are delegated to the
cloning operations for SAB, so no special handling is needed.
Differential Revision: https://phabricator.services.mozilla.com/D61455
When structured clone reads a SAB and creates a new SAB object, or
when it serializes a SAB onto a channel, call a callback that lets the
embedder know. The embedder can then adjust its policy. Concretely,
we want to allow the browser to serialize threads in a process that
uses JS shared memory.
Note, for WebAssembly.Memory, reading and writing are delegated to the
cloning operations for SAB, so no special handling is needed.
Differential Revision: https://phabricator.services.mozilla.com/D61455
nsIMutable is used only by DOM Blob/File. But Blobs are immutable by spec.
FileBlobImpl has a couple of lazy member values, but those are called when
the object is cloned in order to be sent to a different thread/process.
Differential Revision: https://phabricator.services.mozilla.com/D58946
nsIMutable is used only by DOM Blob/File. But Blobs are immutable by spec.
FileBlobImpl has a couple of lazy member values, but those are called when
the object is cloned in order to be sent to a different thread/process.
Differential Revision: https://phabricator.services.mozilla.com/D58716
In order to be able to reasonably debug error results from things like
JSWindowActor.sendQuery, we need to be able to clone errors across process
boundaries, so that they can be propagated to the caller that initiated a
query. The standard for the structured clone algorithm does not allow cloning
errors directly, so this patch instead adds a chrome-only wrapper object which
supports structured clone writing, and on reading, automatically decodes to
the error object it wraps. Callers who wish to clone an Error or Exception
object simply need to wrap it in a ClonedErrorHolder before sending.
Differential Revision: https://phabricator.services.mozilla.com/D50881
In order to be able to reasonably debug error results from things like
JSWindowActor.sendQuery, we need to be able to clone errors across process
boundaries, so that they can be propagated to the caller that initiated a
query. The standard for the structured clone algorithm does not allow cloning
errors directly, so this patch instead adds a chrome-only wrapper object which
supports structured clone writing, and on reading, automatically decodes to
the error object it wraps. Callers who wish to clone an Error or Exception
object simply need to wrap it in a ClonedErrorHolder before sending.
Differential Revision: https://phabricator.services.mozilla.com/D50881
Also, StructuredCloneHolder::CustomWriteTransferHandler() no longer appends an
unused element to mPortIdentifiers when MessagePort::CanBeCloned() returns
false.
Differential Revision: https://phabricator.services.mozilla.com/D55213
Also, StructuredCloneHolder::CustomWriteTransferHandler() no longer appends an
unused element to mPortIdentifiers when MessagePort::CanBeCloned() returns
false.
Differential Revision: https://phabricator.services.mozilla.com/D55213
