This patch makes it so that all target fronts inherits from a Target class mixin.
We are using a mixin as fronts should inherit from a custom Front class,
which is augmented with its own RDP request and events defined in its spec.
(This is done via FrontClassWithSpec(spec))
Depends on D15830
Differential Revision: https://phabricator.services.mozilla.com/D15831
--HG--
extra : moz-landing-system : lando
Creating too many SSOs can apparently slow down the debugger and it's just
wasteful.
This patch passes the SSO down to the cloning functions. One nice side-effect is
that the self-hosting SSO code now lives in SelfHosting.cpp instead of JSScript.cpp
Differential Revision: https://phabricator.services.mozilla.com/D18347
--HG--
extra : moz-landing-system : lando
The logic was redundant with the next step that will already remove all until the next keyframe.
Depends on D18321
Differential Revision: https://phabricator.services.mozilla.com/D18322
--HG--
extra : moz-landing-system : lando
Per spec:
https://w3c.github.io/media-source/#sourcebuffer-coded-frame-removal
Step 3 of the Coded Frame Removal Interval:
"Remove all media data, from this track buffer, that contain starting timestamps greater than or equal to start and less than the remove end timestamp. "
So to decide if a frame should be removed from a track buffer, its start time is the only information to be used.
Differential Revision: https://phabricator.services.mozilla.com/D18321
--HG--
extra : moz-landing-system : lando
I am not a huge fan of the UnwrapReflectorToISupports setup here. Maybe we
should introduce two differently-named methods that make it somewhat clear what
the limitations of not taking a JSContext are? I couldn't think of sane
naming...
Differential Revision: https://phabricator.services.mozilla.com/D17885
--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
This will allow us to correctly handle CheckedUnwrapDynamic on wrappers around
WindowProxy and Location.
Differential Revision: https://phabricator.services.mozilla.com/D17882
--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
Before this patch, if the enterprise roots feature were enabled, nsNSSComponent
would gather any such roots and temporarily import them into NSS so that
CertVerifier could use them during path building and trust querying. This turned
out to be problematic in part because doing so would require unlocking the
user's key DB if they had a password. This patch implements a scheme whereby
nsNSSComponent can give these extra roots directly to CertVerifier, thus
bypassing NSS and any need to unlock/modify any DBs. This should also provide a
path forward for other improvements such as not repeatedly searching through all
certificates on all tokens, which has inefficiencies (see e.g. bug 1478148).
Differential Revision: https://phabricator.services.mozilla.com/D18156
--HG--
extra : moz-landing-system : lando
Whitelist the /Library and ~/Library ColorSync profile directories allowing gfx.color_management.display_profile to be used to load color profiles from those locations.
Differential Revision: https://phabricator.services.mozilla.com/D18390
--HG--
extra : moz-landing-system : lando
So that we can query the test value in the child process properly.
Note that the APIs used for setting the prefers-reduced-motion value for testing
are only used on Android and MacOSX. As for MacOSX we have a different
machinery (see bug 1486971) to deliver the test value without spinning native
event loop in the child process so the change here is valid only for Android.
Differential Revision: https://phabricator.services.mozilla.com/D18311
--HG--
extra : moz-landing-system : lando
I am not a huge fan of the UnwrapReflectorToISupports setup here. Maybe we
should introduce two differently-named methods that make it somewhat clear what
the limitations of not taking a JSContext are? I couldn't think of sane
naming...
Differential Revision: https://phabricator.services.mozilla.com/D17885
--HG--
extra : moz-landing-system : lando
