It doesn't really make sense to enforce this behavior for calls on stack
variables (which presumably we then want to do something with) and doesn't
necessarily make sense to enforce it for member variables either.
Differential Revision: https://phabricator.services.mozilla.com/D46105
--HG--
extra : moz-landing-system : lando
This allows us to create profiler markers whose description contains the name
of the function and its file / line number. This allows the profiler UI to
match up setTimeout callbacks for multiple instances of the same page load, in
order to create meaningful profile comparisons based on markers.
Differential Revision: https://phabricator.services.mozilla.com/D19192
--HG--
extra : moz-landing-system : lando
Consumers that just care about this boolean state should use this instead of
getting the JSObject* directly.
Differential Revision: https://phabricator.services.mozilla.com/D29705
--HG--
extra : moz-landing-system : lando
This allows us to create profiler markers whose description contains the name
of the function and its file / line number. This allows the profiler UI to
match up setTimeout callbacks for multiple instances of the same page load, in
order to create meaningful profile comparisons based on markers.
Differential Revision: https://phabricator.services.mozilla.com/D19192
--HG--
extra : moz-landing-system : lando
For *incoming* wrappers this preserves behavior. We nuke *outgoing* wrappers
when all realms in the compartment have been nuked. To implement this I moved
the wasNuked flag from XPConnect to JS::Compartment as nukedOutgoingWrappers and
to JS::Realm as nukedIncomingWrappers.
The code to create a dead wrapper in the nuked compartment/realm case was also
moved into the JS engine. I added a shell test for it.
Differential Revision: https://phabricator.services.mozilla.com/D14149
--HG--
extra : moz-landing-system : lando
For *incoming* wrappers this preserves behavior. We nuke *outgoing* wrappers
when all realms in the compartment have been nuked. To implement this I moved
the wasNuked flag from XPConnect to JS::Compartment as nukedOutgoingWrappers and
to JS::Realm as nukedIncomingWrappers.
The code to create a dead wrapper in the nuked compartment/realm case was also
moved into the JS engine. I added a shell test for it.
Differential Revision: https://phabricator.services.mozilla.com/D14149
--HG--
extra : moz-landing-system : lando
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).
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 is a large patch which tries to switch many of the external consumers of
nsGlobalWindow to instead use the new Inner or Outer variants.
MozReview-Commit-ID: 99648Lm46T5
We don't have access to an appropriate context to create the dead wrapper in
when the callback is nuked, so instead, this patch creates a new dead wrapper
in the caller compartment each time the property is accessed. This is the same
behavior we'd get when trying to re-wrap a cross-compartment dead wrapper, so
it's consistent with the way we handle these situations elsewhere.
MozReview-Commit-ID: 3cMeR4z8EOe
--HG--
extra : rebase_source : 7e8cf4a195ef64deb7677ce4ac9818d342815667
Boris Zbarsky
Markus Stange
Brindusan Cristian
Jeff Walden
Jan de Mooij
Ciure Andrei
Sylvestre Ledru
Kris Maglione
Daniel Holbert
Olli Pettay
Csoregi Natalia
Nika Layzell
Steve Fink
Thomas Wisniewski
Michael Layzell
Ms2ger