We want to be able to enter the Realm we were in when the callback was created
before calling it, but if the callback stores a cross-compartment wrapper we
don't really have a good way to find that Realm. So we store it explicitly by
storing a global when the callback is created.
The changes to the constructor signatures to use JSObject* instead of
JS::Handle<JSObject*> are so we can avoid having to root the global for these
calls. These changes make two of the constructors ambiguous when nullptr is
being passed for the first arg; this patch adds casts to disambiguate.
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant functions are updated to take a typed enum (in C++) and an
integer constant (in JavaScript). A JavaScript wrapper around the crash
reporter service is provided to hold the constants. The existing whitelists
and blacklists of annotations are also generated from the YAML file and the
existing duplicate code has been consolidated. Once written out to the .extra
file the annotations are converted in string form and are no different than
the existing ones.
All existing annotations have been included (and some obsolete ones removed)
and all call sites have been updated including tests.
--HG--
extra : rebase_source : b4f0d4bf83c64851028c271d3fab3ebcb6fbcd3e
Summary:
DestructValue acts a lot like CleanupValue, however in addition to normal
cleanup work, it invokes the destructor of complex data types. This is important
to ensure that constructors and destructors are matched for these complex data
types.
CleanupValue is also used to clean up a value without destructing it, so cannot
be modified in-place.
Depends On D2689
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1480624
Differential Revision: https://phabricator.services.mozilla.com/D2690
Summary:
This macro simplifies code which allows performing an operation on or
extracting information from a particular nsXPTType's native representation.
It is also used in part 2 to implement xpc::DestructValue.
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1480624
Differential Revision: https://phabricator.services.mozilla.com/D2689
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant functions are updated to take a typed enum (in C++) and an
integer constant (in JavaScript). A JavaScript wrapper around the crash
reporter service is provided to hold the constants. The existing whitelists
and blacklists of annotations are also generated from the YAML file and the
existing duplicate code has been consolidated. Once written out to the .extra
file the annotations are converted in string form and are no different than
the existing ones.
All existing annotations have been included (and some obsolete ones removed)
and all call sites have been updated including tests.
--HG--
extra : rebase_source : f0e8d229581ac5c0daa0e0454cb258746108e28d
I generally tried to preserve the behavior of consumers where they treated an
exception from getInterface(Ci.nsIContentFrameMessageManager) as a signal to use
some sort of fallback.
I did change the behavior of consumers that walked up to the root same-type
docshell before getting the message manager to just get it directly from the
docshell they have. Please review those parts carefully, and let me know if you
want me to ask some subject area experts to review those.
This is done by implementing a fake cubeb backend that implements the subset of
operations we need, while offering an API to be able to control what this
backend is doing.
Because we're reimplementing the private cubeb API, it is necessary to copy
part of a cubeb internal header, and mimick exactly how the vtable mechanism to
do the dynamic dispatch to the diffferent backends in cubeb works. This is not
ideal but works.
When the cubeb API functions are called (from deep in the Gecko process), we
re-bind the call to the mock cubeb backend object and behave exactly like a
normal backend (calling various callbacks and returning fake objects).
Finally, we inject this mock cubeb backend to the running Gecko process (in lieu
of the real one that would have been picked) by setting the global sCubebBackend
variable via a private API exposed only in the test in CubebUtils.h.
MozReview-Commit-ID: 8ZbJhl7pZ2t
--HG--
extra : rebase_source : 922a03fa84803ed04aed633795a54b8d2a305e15
Also, clear the array that's been passed in before appending the new devices.
MozReview-Commit-ID: BTnwzyKBrb5
--HG--
extra : rebase_source : 23dbd11720804a30188389bc4408be4b40ad70b2
This is for testing purposes only. Defining ENABLE_SET_CUBEB_BACKEND before
including CubebUtils.h will expose the function. This is not to be set outside
of test files.
MozReview-Commit-ID: D0V8oLj9xo6
--HG--
extra : rebase_source : e80d4c01ff3b28c300de1e6819477ea732c2f157
This is slightly slower, especially if the main thread is busy, but it's cleaner
and actually safe.
MozReview-Commit-ID: 4C2FalxmE3L
--HG--
extra : rebase_source : 3f1341397bede31fcc35dab5a0cbf59b893f9b81
For an AudioCallbackDriver, the number of input channels is immutable, and
passed at construction, so that it's less necessary to rely on global state.
MozReview-Commit-ID: F9TL1H92z3W
--HG--
extra : rebase_source : 5193488592ca97273eb2b6f43d4c7a0e4beb0a33
The MSG now can feed microphone data to all its input listeners. This paves the
way for multiple input device, if we feel it's needed at some point, but does
not implement it.
The method for adding/removing inputs are also cleaned up.
MozReview-Commit-ID: 9OX4Da6Gjq2
--HG--
extra : rebase_source : 043c486e53f9220ae61fd788ed86064ba723f1a4
beforeTestSync uses an asynchronous operation that takes a while to finish.
In the meantime, it's very likely that the browser will run some tasks
scheduled to run when idle, which cause XPCOMUtils mock in browser-test.js
to be used, which references _globalProperties.
--HG--
extra : rebase_source : 3d75068a43cad4e87317792c67b6fe5fd483f0c5
TypedObjects that map Wasm structs with fields that have Ref type are
not yet constructible from JS because the type constraint can't be
honored. So for now, make it possible for Wasm to flag such structs
as unconstructible-from-JS.
--HG--
extra : rebase_source : aab9d7f2ba7b4c1ff7875d184b86bb0ae3e32413
extra : intermediate-source : 97c72ae6e843fe1cb712bd4855d174fc711c3cb0
extra : source : f59588ebc5c4ff06bfb437896147e07cb856e355
This allows internal clients (notably Wasm) to flag TO fields as
immutable; we need this both to provide immutability for fields that
are declared immutable in wasm structs, and to temporarily avoid the
need for type constraints on assignments to Ref-typed pointer fields.
--HG--
extra : rebase_source : 19d1b1bf81396ca305b699cda0277fd8e41f5fe9
extra : intermediate-source : d219c9587f920a0f5924dbdab3e8cf5dfecf3f75
extra : source : f1161dd31ac1cf6f050315d04b978b9d6c0c824a