We could make sure we serialize TimingFunction for both computed
and specified values with servo (via CSSOM). However, Web animation
APIs could also serialize the timing function from a different code
path. We will fix it in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D10443
--HG--
extra : moz-landing-system : lando
Switch over to mozilla::TimeStamp for timing. This should use clock_gettime, mach_absolute_time, ,and QueryPerformanceCounter timing implementations on Linux, OSX, and Windows which are all very efficient. It increases overhead a little bit, but allows for synchronization across cores and the profiler, and is portable. Longer term solution should be to move over to rdtscp for timing.
Differential Revision: https://phabricator.services.mozilla.com/D10588
--HG--
extra : moz-landing-system : lando
The implementation of deferred transforms did not handle the case where
we ended up deferring multiple transform items in a row with different
ASRs. In this case, when we encounter the nested transform item that we
want to defer, we need to flush the previously-deferred transform item
into a WebRenderLayerScrollData item. This patch accomplishes that, and
includes a mochitest that exercises the relevant behaviour.
Depends on D8110
Differential Revision: https://phabricator.services.mozilla.com/D8111
--HG--
extra : moz-landing-system : lando
The implementation of deferred transforms did not handle the case where
we ended up deferring multiple transform items before encountering the
APZ-relevant display item. In this case we need to somehow accumulate
all the deferred transforms. This patch accomplishes that, and includes
a mochitest that exercises the relevant behaviour.
Depends on D8109
Differential Revision: https://phabricator.services.mozilla.com/D8110
--HG--
extra : moz-landing-system : lando
This code will be expanded a bit in the next few patches, so hopefully
the comments here provide a reasonable explanation of what this code is
about.
Differential Revision: https://phabricator.services.mozilla.com/D8108
--HG--
extra : moz-landing-system : lando
Summary:
Makes CityHash64, CityHash64WithSeed, and CityHash64WithSeeds usable from C code
Removes unnecessary includes from mar_read.c as well
Reviewers: rstrong
Reviewed By: rstrong
Subscribers: ulfr, dveditz, tjr, mhowell, jmathies, rstrong, jewilde
Tags: #secure-revision, #bmo-toolkit-core-security
Bug #: 1468544
Differential Revision: https://phabricator.services.mozilla.com/D10426
--HG--
extra : rebase_source : 4e3f97e07e7a17c454d22b80aa37752e31328224
extra : amend_source : d455610bb6c247401134b0a29070c3b48a0f01c4
This will be used by GeckoView to set initial pref values that would
normally come from prefs.js or similar on desktop and Fennec.
Differential Revision: https://phabricator.services.mozilla.com/D9820
We don't want to store a persistent value for these prefs because
the value is managed by the app via GeckoRuntimeSettings. Using
the default branch is the best way to do this currently, though
it does mean the value could be shadowed by a user pref. To combat
this we also reset any of the user prefs that are managed
via GeckoRuntimeSettings.
Differential Revision: https://phabricator.services.mozilla.com/D9818
This exposes Gecko networking to GeckoView apps. It includes speculative connections, name resolution, and a Fetch-like HTTP API.
Differential Revision: https://phabricator.services.mozilla.com/D7799
squash to executor
