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
This allows calling a C++ MOZ_CAN_RUN_SCRIPT method that takes a callback argument.
The changes to TestCanRunScript.cpp are there to catch an incorrect change I was
going to make to the analysis to make this work, until I figured out that
RootedCallback should be MOZ_IS_SMARTPTR_TO_REFCOUNTED.
Differential Revision: https://phabricator.services.mozilla.com/D23519
--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
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.
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
Some places call CallbackPreserveColor() because they know the object
must have already been marked black. This patch replaces those calls
with a new function CallbackKnownNotGray() which documents and
dynamically checks this assumption.
Rooted used to only work when the JSContext was in a request. This has long
been rectified, so the comments referring to that constraint are confusing at
best.
