Because XrayTraits::attachExpandoObject operates in the Xray target realm/compartment and we cannot use the Xray wrapper with JSAutoRealm, we pass the caller's global as exclusiveWrapperGlobal and use that.
This also changes XrayWrapper<Base, Traits>::defineProperty to call ensureExpandoObject in the wrapper (instead of target) realm. This didn't matter before, because ensureExpandoObject immediately entered the target realm anyway.
Because getOwnPropertyFromTargetIfSafe operates in the Xray target realm/compartment and we cannot use the Xray wrapper with JSAutoRealm, we pass the caller's global as wrapperGlobal and use that.
Right now, a lot of test code relies on side-effects of SpecialPowers being
loaded into frame script globals. In particular:
- It forces permissive COWs from those scopes, which allows frame scripts to
pass objects from those scopes to unprivileged content that they otherwise
wouldn't.
- It imports a bunch of helper modules and WebIDL globals which would
otherwise not be available.
Fortunately, this seems to only impact test code at this point. But there's a
real down-the-road risk of it impacting shipping code, which ends up working
in automation due to the side-effects of SpecialPowers, but failing in real
world use.
MozReview-Commit-ID: G27eSSOHymX
--HG--
extra : rebase_source : 1702e63fed719fc92def2bdbbb8a7c53572432db
extra : source : 41bedc526dd6ec6b7e8c7be1c832ac60c81d6263
Right now, a lot of test code relies on side-effects of SpecialPowers being
loaded into frame script globals. In particular:
- It forces permissive COWs from those scopes, which allows frame scripts to
pass objects from those scopes to unprivileged content that they otherwise
wouldn't.
- It imports a bunch of helper modules and WebIDL globals which would
otherwise not be available.
Fortunately, this seems to only impact test code at this point. But there's a
real down-the-road risk of it impacting shipping code, which ends up working
in automation due to the side-effects of SpecialPowers, but failing in real
world use.
MozReview-Commit-ID: G27eSSOHymX
--HG--
extra : rebase_source : c528dffe3a54eec75ad6cb358980b783b00eb4a4
The problem we're solving here: getting/entering the realm/global of a cross-compartment wrapper doesn't make sense once there are multiple realms in a compartment and the CCW will be shared by all of them. Because nsXPCWrappedJS can store a CCW, we will no longer be able to use this JSObject to enter the target realm.
What this patch does: we pass a JSContext* to nsXPCWrappedJS::GetNewOrUsed and we use this to store a global object in nsXPCWrappedJS (with the invariant that the object and global stored in nsXPCWrappedJS are same-compartment). Then when we want to enter the nsXPCWrappedJS's target realm, we use this global object instead of the maybe-CCW object. Because we currently still have one realm per compartment and the objects are same-compartment, this is guaranteed to preserve behavior for now.
nsXPCWrappedJS has some code to deal with weak pointers. Fortunately this applies only to root wrappers and root wrappers always store an unwrapped JSObject, so the extra global we store is guaranteed to be marked by the GC in that case (a global object is never collected when there are live JSObjects belonging to the same realm).
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
In PLDHashTable the equivalent functions have a "Shallow" prefix, which makes
it clear that they don't measure things hanging off the table. This patch makes
mozilla::Hash{Set,Map} do likewise.
MozReview-Commit-ID: 3kwCJynhW7d
--HG--
extra : rebase_source : 9c03d11f376a9fd4cfd5cfcdc0c446c00633b210
Summary:
This more closely matches the C++ names, and reflects the fact that the
reflected type is not WebIDL's mozilla::dom::Sequence. The reasoning behind this
type difference is for ergonomics, due to xpidl only being exposed to internal
JS code.
Depends On D2335
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2337
Summary:
This is done so we can use Array as the name for the new nsTArray-based
type, rather than having to come up with a new name.
LegacyArray was chosen as the [array] attribute is now effectively deprecated,
and we'd like to remove it ASAP.
Depends On D2334
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2335
Summary:
This means that using these types involves many fewer footguns, while not
requiring any changes to the actual XPConnect implementation!
Depends on D2111
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2334
Summary:
This should make it more clear which types have which behaviours, and should
make it easier to add new types without forgetting to handle a special case
somewhere.
Depends On D2114
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1475409
Differential Revision: https://phabricator.services.mozilla.com/D2115
This will get us both more clarity as to what types are, but also will improve switch exhaustiveness checks.
Summary: Depends On D2113
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1475409
Differential Revision: https://phabricator.services.mozilla.com/D2114
