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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
The basic idea for the changes around UnwrapObjectInternal and its callers
(UnwrapObject, UNWRAP_OBJECT, etc) is to add a parameter to the guts of the
object-unwrapping code in bindings which can be either a JSContext* or nullptr
(statically typed). Then we test which type it is and do either a
CheckedUnwrapDynamic or CheckedUnwrapStatic. Since the type is known at
compile time, there is no actual runtime check; the compiler just emits a call
to the right thing directly (verified by examining the assembly output on
Linux).
The rest of the changes are mostly propagating through that template parameter,
adding static asserts to make sure people don't accidentally pass nullptr while
trying to unwrap to a type that might be a WindowProxy or Location, etc.
There are also some changes to places that were calling CheckedUnwrap directly
to use either the static or dynamic version, as needed.
Differential Revision: https://phabricator.services.mozilla.com/D17883
--HG--
extra : moz-landing-system : lando
The basic idea for the changes around UnwrapObjectInternal and its callers
(UnwrapObject, UNWRAP_OBJECT, etc) is to add a parameter to the guts of the
object-unwrapping code in bindings which can be either a JSContext* or nullptr
(statically typed). Then we test which type it is and do either a
CheckedUnwrapDynamic or CheckedUnwrapStatic. Since the type is known at
compile time, there is no actual runtime check; the compiler just emits a call
to the right thing directly (verified by examining the assembly output on
Linux).
The rest of the changes are mostly propagating through that template parameter,
adding static asserts to make sure people don't accidentally pass nullptr while
trying to unwrap to a type that might be a WindowProxy or Location, etc.
There are also some changes to places that were calling CheckedUnwrap directly
to use either the static or dynamic version, as needed.
Differential Revision: https://phabricator.services.mozilla.com/D17883
--HG--
extra : moz-landing-system : lando
The basic idea for the changes around UnwrapObjectInternal and its callers
(UnwrapObject, UNWRAP_OBJECT, etc) is to add a parameter to the guts of the
object-unwrapping code in bindings which can be either a JSContext* or nullptr
(statically typed). Then we test which type it is and do either a
CheckedUnwrapDynamic or CheckedUnwrapStatic. Since the type is known at
compile time, there is no actual runtime check; the compiler just emits a call
to the right thing directly (verified by examining the assembly output on
Linux).
The rest of the changes are mostly propagating through that template parameter,
adding static asserts to make sure people don't accidentally pass nullptr while
trying to unwrap to a type that might be a WindowProxy or Location, etc.
There are also some changes to places that were calling CheckedUnwrap directly
to use either the static or dynamic version, as needed.
Differential Revision: https://phabricator.services.mozilla.com/D17883
--HG--
extra : moz-landing-system : lando
JSStackFrames are C++ objects that are exposed to chrome JS and keep
alive content JS. This means that if chrome JS leaks a stack frame
then a window can be leaked.
The basic idea of this patch is to think of JSStackFrames as
cross-compartment wrappers, and do a "hueyfix" on them by dropping the
content JS reference when the associated content window is closed.
To do that, this patch modifies the realm private to keep a list of
all live JSStackFrames that have been created with objects in that
realm. When we nuke that realm, we also clear out all of the JS
pointers from the registered stack frames on that realm.
This adds a hash table lookup to the JSStackFrame ctor and dtor, which
is hopefully not too much overhead.
The test works by intentionally leaking a JSStackFrame from chrome JS
and making sure that the window still goes away.
Differential Revision: https://phabricator.services.mozilla.com/D14880
--HG--
extra : moz-landing-system : lando
JSStackFrames are C++ objects that are exposed to chrome JS and keep
alive content JS. This means that if chrome JS leaks a stack frame
then a window can be leaked.
The basic idea of this patch is to think of JSStackFrames as
cross-compartment wrappers, and do a "hueyfix" on them by dropping the
content JS reference when the associated content window is closed.
To do that, this patch modifies the realm private to keep a list of
all live JSStackFrames that have been created with objects in that
realm. When we nuke that realm, we also clear out all of the JS
pointers from the registered stack frames on that realm.
This adds a hash table lookup to the JSStackFrame ctor and dtor, which
is hopefully not too much overhead.
The test works by intentionally leaking a JSStackFrame from chrome JS
and making sure that the window still goes away.
Differential Revision: https://phabricator.services.mozilla.com/D14880
--HG--
extra : moz-landing-system : lando
This removes AutoMaybeEnterFrameRealm. Most places pass cx->realm->principals: it preserves behavior when the (possibly wrapped) SavedFrame and cx are same-compartment. The main exception is the JSStackFrame DOM bindings code where we have to be a bit smarter about which principals to use.
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Before this commit, one could either capture all stack frames (by passing
maxFrameCount = 0) or a maximum of N frames (by passing maxFrameCount = N). This
commit introduces the ability to capture the first frame (by default ignoring
self hosted frames) with some target principals. This new option required
replacing the `unsigned maxFrameCount` parameter with the introduction of a new
sum type to describe the stack capturing behavior:
StackCapture = AllFrames
| MaxFrames(unsigned n)
| FirstSubsumedFrame(JSPrincipals* p, bool ignoreSelfHosted)
This is obviously more wordy in C++ than we'd like, but does make the stack
capturing more explicit rather than relying on the sentinal 0 to stand in for
infinity.
Kris Maglione
Ciure Andrei
Sylvestre Ledru
Brian Hackett
Boris Zbarsky
Gurzau Raul
Andrew McCreight
Andreea Pavel
Jeff Walden
Jan de Mooij
Emilio Cobos Álvarez
Karl Tomlinson
Jason Orendorff
Jon Coppeard
Masatoshi Kimura
Andrea Marchesini
Olli Pettay
Michelangelo De Simone
Kaku Kuo
Terrence Cole
Nick Fitzgerald
Wes Kocher