selectAudioOutput() grants are per-device, but getUserMedia() grants expose all
speakers associated with any microphone.
When exposed, speaker devices have labels even when there is no active capture device.
Differential Revision: https://phabricator.services.mozilla.com/D118443
This will be used to limit exposure of audio output devices by group id.
Exposure of microphone devices is not yet limited but covered by bug 1528042.
Depends on D118441
Differential Revision: https://phabricator.services.mozilla.com/D118442
This is the main part to address bug 1701368.
Before this patch, `nsAvailableMemoryWatcher` directly broadcasted a memory-pressure
event when we enter into a low-memory situation and `TabUnloader` unloaded a tab in
response to the memory-pressure message. We want to decouple `TabUnloader` from
memory-pressure listeners because unloading a tab may solve a low-memory situation
alone.
With this patch, if `nsAvailableMemoryWatcher` detects a low-memory situation,
it invokes `TabUnloader` synchronously via an XPCOM interface. If `TabUnloader`
unloads a tab, we don't do any further action. If there is no discardable tab,
`TabUnloader` notifies back `nsAvailableMemoryWatcher` via another XPCOM interface,
so that `nsAvailableMemoryWatcher` can notify of a memory-pressure event.
Differential Revision: https://phabricator.services.mozilla.com/D117673
This patch introduces an XPCOM object which is represented by the single instance of
`nsAvailableMemoryWatcherBase` so that `nsAvailableMemoryWatcher` can synchronously
access `TabUnloader`.
We currently implement a watcher class for Windows only. For other platforms, what
we need to do is to define a class inherinting `nsAvailableMemoryWatcherBase` and
a simple factory method `CreateAvailableMemoryWatcher()` returning an instance of
that class.
Differential Revision: https://phabricator.services.mozilla.com/D118393
This patch removes dependency on the available physical memory.
With this patch, `nsAvailableMemoryWatcher` triggers `OnLowMemory` when the available
commit space is low, and triggers `OnHighMemory` when the available commit space is
no longer low.
The key part of this change is the `if` block in `nsAvailableMemoryWatcher::Notify`,
where we use a single condition `IsCommitSpaceLow()` to declare either Low or High.
After this change, `OnLowMemory` is called not only in the main thread but also in
a worker thread. So `StartPollingIfUserInteracting` also needs a lock to protect
`mPolling`.
Differential Revision: https://phabricator.services.mozilla.com/D117672
We had `NS_DispatchMemoryPressure` and `NS_DispatchEventualMemoryPressure`
to dispatch a memory-pressure event which took `MemPressure_New` and
`MemPressure_Ongoing` to translate into "low-memory" and "low-memory-ongoing"
message respectively.
With that model, we could end up sending a wrong message if somebody
called the API with `MemPressure_Ongoing` without sending `MemPressure_New`.
To avoid that, this patch removes `MemPressure_Ongoing` and makes
the API decide whether it should dispatch a "new" event or "ongoing" event.
Differential Revision: https://phabricator.services.mozilla.com/D119122
1. Use `nsAutoHandle` instead of a raw `HANDLE`
2. Add a dtor with `MOZ_ASSERT`
3. Prevent double init
4. Cache `nsAvailableMemoryWatcher::mObserverSvc`
Differential Revision: https://phabricator.services.mozilla.com/D117670
This patch splits `nsAvailableMemoryWatcher` into 1) an nsISupports-derived class
`nsAvailableMemoryWatcherBase` and 2) a platform-specific class `nsAvailableMemoryWatcher`,
taking out the 2) part as a new file AvailableMemoryWatcherWin.cpp without any change.
Test cases for `nsAvailableMemoryWatcher` will be added by a subsequent patch.
Differential Revision: https://phabricator.services.mozilla.com/D117669
This allows to use the same toolchain docker images as other toolchains,
based on Debian buster.
While here, use the default max-run-time, which is more than enough for
this toolchain.
Differential Revision: https://phabricator.services.mozilla.com/D119137
Because GCC is built in stages, the final stage is built with
intermediate stages's GCC, which handles the sysroot correctly, so we
end up with headers and libraries with the expected compatibility.
This allows to use the same toolchain docker images as other toolchains,
based on Debian buster.
Differential Revision: https://phabricator.services.mozilla.com/D119136
- we needed -gcc-toolchain to pick C/C++ standard headers from the right
version of GCC, but we now have them in the toolchain sysroot (bug
1719207), so we can use that instead.
- we needed LD_LIBRARY_PATH when clang was built on an older version of
Debian, but that was changed in bug 1694775.
Differential Revision: https://phabricator.services.mozilla.com/D119135
We have a separate binutils toolchain already, and the only remaining
use of the binutils part of the the GCC toolchain is for the gold plugin
headers for clang, which we can add to the toolchain sysroot.
Differential Revision: https://phabricator.services.mozilla.com/D119133
Previously, the child primitives of off-screen surfaces were not
being atomically treated as a single unit. This meant that the
primitives may be assigned to different sub-slices, under certain
edge case conditions.
As a short term fix, let the picture cache code know when an off
screen surface is being processed during primitive dependency
updates. This ensures that all child primitives within a surface
will be assigned to the same sub-slice.
Differential Revision: https://phabricator.services.mozilla.com/D119052