We're going to need this because we will have multiple Realms in the same
compartment which want different CheckedUnwrap behavior in some cases. So we
need to be able to check which Realm we're in.
Differential Revision: https://phabricator.services.mozilla.com/D17881
--HG--
extra : moz-landing-system : lando
We're going to need this because we will have multiple Realms in the same
compartment which want different CheckedUnwrap behavior in some cases. So we
need to be able to check which Realm we're in.
Differential Revision: https://phabricator.services.mozilla.com/D17881
--HG--
extra : moz-landing-system : lando
I am bit surprised myself, but just removing the getPropertyDescriptor trap seems to mostly work.
The only real special case here is the XPC Sandbox, which I changed to keep using its getPropertyDescriptorImpl.
testSetPropertyIgnoringNamedGetter.cpp didn't even really need its getPropertyDescriptor implementation.
Differential Revision: https://phabricator.services.mozilla.com/D17386
--HG--
extra : moz-landing-system : lando
I'm always forgetting which code path is which. So give both these
functions clearer names that say if they're used by profiling or telemetry.
--HG--
extra : rebase_source : 8edcabba510bcf7170b7e071f7cb3a21be23b0e4
This patch removes the StopWatch code that was used in the first version of
about:performance, and not being used anymore.
Differential Revision: https://phabricator.services.mozilla.com/D7453
--HG--
extra : moz-landing-system : lando
This case can come up with same-compartment realms. Keeping these CCWs
would confuse RemapWrapper because it'd be called with the CCW and target
in the same compartment.
Differential Revision: https://phabricator.services.mozilla.com/D15491
--HG--
extra : moz-landing-system : lando
This needs to be on the compartment to prevent creating duplicate wrapped natives.
We now also allocate these objects in the compartment's first global for
consistency and to prevent leaks.
XPCWrappedNativeScope also stores the content XBL scope. I considered moving
this to RealmPrivate, but given the fate of in-content XBL I went with the
simpler option of keeping it on XPCWrappedNativeScope and release-asserting we
have a single realm in the XBL case.
Because XPCWrappedNativeScope no longer stores a global object, we no longer
need XPCWrappedNativeScope::TraceSelf, XPCWrappedNativeProto::TraceInside and
XPC_WN_Proto_Trace.
Differential Revision: https://phabricator.services.mozilla.com/D14849
--HG--
extra : moz-landing-system : lando
Move js/src/jsapi.h declarations related to promises and job queues into their
own public header file, js/public/Promise.h. Change the compilation units that
need these declarations to #include the new header.
There should be no changes to the actual functionality here, simply moving the
code to a new file, and removing the "JS" prefix from some typedefs which are
now in the JS namespace.
Differential Revision: https://phabricator.services.mozilla.com/D13345
--HG--
extra : moz-landing-system : lando
Replace with just unwrapping the key, since there are no users that return anything else for a delegate.
--HG--
extra : rebase_source : e72b825121ca3493364c9347f65e5dddd1ef53e0
CCWs are not really associated with a single realm and we assert code doesn't
enter/request the realm or global of a CCW. However they currently still have an
ObjectGroup that's associated with a single realm. Using the same realm avoids
some potential memory usage issues.
Differential Revision: https://phabricator.services.mozilla.com/D14531
--HG--
extra : moz-landing-system : lando
Boris Zbarsky
Gurzau Raul
André Bargull
Tom Schuster
Jeff Walden
Oana Pop Rus
Jon Coppeard
Andy Wingo
Dorel Luca
Razvan Maries
Sylvestre Ledru
Ehsan Akhgari
Paul Bone
Tarek Ziadé
Brian Hackett
Jan de Mooij
inspiro
Jim Blandy
arthur.iakab
Steve Fink
Margareta Eliza Balazs
Brindusan Cristian