- Refactored gfxVROpenVR to use gfxVRExternal interface from the
VR Service. Existing gfxVROpenVR left in place (for now) to
allow VR service to be enabled or disabled by pref.
- The VR service, containing gfxVROpenVR, is to run in-process within
its own thread first, then to be later moved to its own process.
- Fixed periodic immersive mode flicker that occured due to HMD pose and
HMD state being separately sampled from the Shmem. It was possible
to advance a frame without also getting an updated pose if a dirty
copy of the shmem was detected.
MozReview-Commit-ID: IvpJErmi5kF
--HG--
extra : rebase_source : 0e21d3414a13dc514c3035f2bd5f6adc365b465d
This reduced the additional string duplication that we currently do every time
we add a preference observer.
It changes the string that we store in the observer objects to be absolute,
rather than relative to the branch, but keeps the semantics the same, by
resolving the full preference name in the places we were previously matching
by relative string.
This actually has the effect of simplifying a lot of code, since the absolute
preference name is usually what we want.
MozReview-Commit-ID: 10WjHb0tNGB
--HG--
extra : rebase_source : b3cb0ba103fc239e42459e77cd389db0b5ecde18
Most preference callbacks use literal strings for their domain filters, which
means that there's no need to make copies of them at all. Currently, however,
every preference observer node makes a separate heap-allocated copy of its
domain string.
This patch switches the domain string storage to nsCString instances, which
dramatically reduces the amount of unnecessary copies, at the expense of
making the callback nodes slightly larger.
MozReview-Commit-ID: 8NA3t2JS2UI
--HG--
extra : rebase_source : 628ad9af65cec16fb8be0c8dddc608b5ee5602e2
Summary:
This will allow to be called from the MediaCapabilities taskqueue if we find that a decoder won't be hardware accelerated.
It is still assumed that Benchmark::Init() was called at least once on the main thread.
Depends on D1628
Tags: #secure-revision
Differential Revision: https://phabricator.services.mozilla.com/D1767
Test that a video which tries to autoplay via either a play() call or via
an autoplay attribute:
* Plays when it has a pre-existing "allow" autoplay-media permission.
* Is blocked when it has a pre-existing "block" autoplay-media permission.
* Plays when it doesn't have a pre-existing autoplay-media permission and
"allow" is pressed on the door hanger.
* Is blocked when it doesn't have a pre-existing autoplay-media permission and
"block" is pressed on the door hanger.
MozReview-Commit-ID: CpftV6RQbtU
--HG--
extra : rebase_source : a9c38a7e7071e3ebd34f10175f4f22cd84c4c303
Dropbox has fixed the bug by their side. Therefore, we can drop
"paper.dropbox.com/doc" from the blacklist now.
MozReview-Commit-ID: 9nWdmDQ0sSY
--HG--
extra : rebase_source : 5a348f879857a88a33e52753cc9b1d3f1ecc0e11
Feature is mature and doesn't need pref.
In fact, it was not used in code anymore, only in tests.
MozReview-Commit-ID: AbH8OCiksDa
--HG--
extra : rebase_source : b9a7d18b3c1b948f213632a16d2152f80d676068
The new pref is "network.dns.resolver-thread-extra-idle-time-seconds"
The default is 60 seconds. This means that threads will stay idle for an extra 60 seconds, after which they are shutdown.
Setting the pref to 0 would preserve the behaviour before the threads were swiched to use nsThreadPool - meaning that they would be shutdown immediately after ThreadFunc completes.
Setting the pref to -1 would keep the threads alive forever.
MozReview-Commit-ID: CoUB5gan4MR
--HG--
extra : rebase_source : 7b444789eebaf43c939ce9d7153218c4cd594b65
The 'all' shorthand has shipped a long time ago, so this pref is not needed
anymore.
MozReview-Commit-ID: GND8qSVAfCG
--HG--
extra : rebase_source : 10708e749911fa95554ed423a5782db61df67cd0
Summary:
This patch adds the infrastructure to move Activity Stream (about:newtab, about:home,
and about:welcome) into its own special content process - the privileged content
process. This feature of running Activity Stream in the privileged content process
is disabled by default. (See "browser.tabs.remote.separatePrivilegedContentProcess"
preference.) We can deal with other about: pages in a follow-up.
Reviewers: mconley
Tags: #secure-revision
Bug #: 1469072
Differential Revision: https://phabricator.services.mozilla.com/D1731
MozReview-Commit-ID: 5gIrP4LxcIt
--HG--
extra : rebase_source : d43c411ae60aad3d5a3a496e6729de0b547b4acd
- Introduced the io.activity.enabled pref, so IOActivityMonitor can run without a timer
- Added IOActivityMonitor::NotifyActivities() to trigger notifications manually
- Added ChromeUtils.requestIOActivity() so we can trigger it via JS
MozReview-Commit-ID: 9JA2rLaM496
--HG--
extra : rebase_source : e473a7b0ec7c231ab321846c5ddcc4d6a88d7245
This pref can be used by users to force-disable WebRender. It is
recorded in the telemetry environment so we can get a sense of how many
people are setting this pref.
MozReview-Commit-ID: yZSN44NMvD
--HG--
extra : rebase_source : d355236773f63da0f6acb5341f4ae6a88cd0a488
- Introduced the io.activity.enabled pref, so IOActivityMonitor can run without a timer
- Added IOActivityMonitor::NotifyActivities() to trigger notifications manually
- Added ChromeUtils.requestIOActivity() so we can trigger it via JS
MozReview-Commit-ID: 9JA2rLaM496
--HG--
extra : rebase_source : 0a92195b6b8314383c63de4b2bb1dfe033c40e9f
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : dd000a05bfc2da40c586644d33ca4508fa5330f6
