This has never been specced and is unused appart from our tests.
Differential Revision: https://phabricator.services.mozilla.com/D10082
--HG--
extra : rebase_source : c044f11325ec630dcabb673c85531a2283ff6ad4
extra : source : db3c2a88f79cb28440f4e13bcf27c5165c6ee060
This has never been specced and is unused appart from our tests.
Differential Revision: https://phabricator.services.mozilla.com/D10082
--HG--
extra : rebase_source : 4c54d808fb69c0e403ff2e1775b97571889efca4
extra : histedit_source : bc568066b0684bb82b4f553b99f0dd48212aa633
Implement a new method in MediaManager that enumerates audio output devices and looks up for a given sink id asynchronously.
Differential Revision: https://phabricator.services.mozilla.com/D5870
--HG--
extra : moz-landing-system : lando
MediaDevice is the core object for audio device enumeration. By adding AudioDeviceInfo every information of audio devices will be available. In this case device id will be available from the first enumeration and there is no need to enumerate multiple times to get that info.
Differential Revision: https://phabricator.services.mozilla.com/D5869
--HG--
extra : moz-landing-system : lando
Check if we have permission from the OS to access the camera and microphone after the user has granted access to a site.
If permission is denied at the OS level, but granted to the site within Firefox, return NotFoundError.
Differential Revision: https://phabricator.services.mozilla.com/D5458
--HG--
extra : moz-landing-system : lando
It's not maintained and probably does not work anymore.
Differential Revision: https://phabricator.services.mozilla.com/D5438
--HG--
extra : rebase_source : ccd622e40844dda5d16266e49991462d4ea94224
nsGlobalWindowInner::GetExtantDoc() can potentially return null, and
we're not null checking its return value in
MediaManaager::IsActivelyCapturingOrHasAPermission() which I think is the
cause of this crash.
So instead of getting the principal from the window's extant doc, we can
get the principal directly from the nsGlobalWindowInner.
MozReview-Commit-ID: BUwiJGLss2a
--HG--
extra : rebase_source : 5135a2ef524044c44046705f4a7c7516f01f6b34
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Focusing a source during a test run can cause Firefox to lose focus and
subsequent tests to timeout. This adds a preference which defaults to true
that allows the source to be focused. It is then set to false for tests that
involve screen sharing.
MozReview-Commit-ID: CNq2c87y8Ho
--HG--
extra : rebase_source : 805e2cbf9c09af419419a64d074e020784185b1d
This adds a FocusOnSelectedSource method to PCameras and uses it to focus the
selected window while window sharing. We can't just focus the window as soon as
it is shared because we have a live preview in the getUserMedia permissions
prompt which would cause the prompt to lose focus. Instead, this only focuses the
window when the sharing is not done from a chrome context.
MozReview-Commit-ID: 5jre75E3JLi
--HG--
extra : rebase_source : 5f5154fc9fc7590cc02eb25146e5bc20b2243fa3
This adds a FocusOnSelectedSource method to PCameras and uses it to focus the
selected window while window sharing. We can't just focus the window as soon as
it is shared because we have a live preview in the getUserMedia permissions
prompt which would cause the prompt to lose focus. Instead, this only focuses the
window when the sharing is not done from a chrome context.
MozReview-Commit-ID: 5jre75E3JLi
--HG--
extra : rebase_source : 97f472f6ed1c5d6bed1af01fb7243a82b2629b03
Update the DeviceEnumerationType enum to scoped style enum for safety and
consistency. Add extra logging to aid in debugging test issues.
MozReview-Commit-ID: cm5bdlIcEG
--HG--
extra : rebase_source : bfcae3d49f809edfd0ed6ab3e516b8be0c0d517e
Change the media manager so that if fake and loopback devices are requested,
loopback is preferred. With this change loopback and fake devices can also be
mixed. Since the fake flag is coarse, and does not specify fake audio or video,
we would previously just make everything fake. As loopback sets flags for video
and audio separately, we can now request a single loopback device, while also
setting the fake flag to get a mix. E.g. if we request a loopback audio device,
and set the fake flag, we should get loopback audio and fake video.
This change also attempts to somewhat consolidate where these settings take
place. Previously, EnumerateRawDevices did much of the loopback setup. However,
other steps around fingerprint resistance or fake devices were done in earlier
functions (EnumerateDevices and GetUserMedia). This changeset moves the loopback
setup so that it's more consolidated with the other setup code in these
functions.
MozReview-Commit-ID: FF0bR0Nyws9
--HG--
extra : rebase_source : 374a6fd0842a430e27c695bcf956e2e072a77fc3
Prior to this patch various bools are used to track if we requst fake or
loopback devices during enumeration. However, since the normal, fake, and
loopback cases are mutually exclusive, a enum can be used. This provides allows
for having descriptive enum values in code and makes clear that the settings are
mutually exclusive.
MozReview-Commit-ID: FF0bR0Nyws9
--HG--
extra : rebase_source : 498513bdc6673fa299080097364a6d0dff00a073
Add logging was added to help diagnose gUM failures and provide more log
coverage of that code path.
MozReview-Commit-ID: A76fjlUVpmn
--HG--
extra : rebase_source : 6f67ab223739474c8dec7a72a1ff322503c4df96
The previous assertion was from an earlier developer stage which changed
during development of bug 1299515. It assumed that mDeviceEnabled was
updated only after passing the assert.
In the final version of bug 1299515 that is no longer true, and
both the failed and the successful device operation asserts
can now be unified to one.
MozReview-Commit-ID: KMdnIs0UgPr
--HG--
extra : rebase_source : 936900db168623f913aaa76a9148d4ee80157493
This so that SourceListener can keep its internal state in sync with the result
of the start operation.
MozReview-Commit-ID: Cgl5TFnpCeW
--HG--
extra : rebase_source : e2cec60544efcc27c9c8c077fbdb013a8f3b848c
extra : source : 6c38cc382d2114199842dddb14097be8b6d9a961
extra : histedit_source : 00ef8da067eb484b8c5926d008f00f1e9f006e6f
This so that SourceListener can keep its internal state in sync with the result
of the start operation.
MozReview-Commit-ID: Cgl5TFnpCeW
--HG--
extra : rebase_source : 4a7e8c1217b0db3879312d4b33dc74227e969608
With the added invariant that NotifyPull() needs a MediaStreamListener present
to not underrun, we need SetPullEnabled() and AddListener() to stay in sync by
using the same signaling mechanism.
MozReview-Commit-ID: 49KWdiTOG98
--HG--
extra : rebase_source : d0ad44d7ce431aa792c4908f96baf0c0920dbe90
This modifies mediaCaptureWindowState() to say whether a camera or microphone is
actively captured or not. Note that this is not the same as the device being
on or off. If we disallow a device from being off while disabled, we still
notify chrome that we're not actively capturing.
MozReview-Commit-ID: B1taormqc3j
--HG--
extra : rebase_source : 292d323c4b9711cc242170f5c5c139bb87658c44
This wires up the disabling of a track with actually stopping the device if we
allow it.
This is possible for:
- Camera (enabled by default, controlled by pref
"media.getusermedia.camera.off_while_disabled.enabled")
- Microphone (disabled by default, controlled by pref
"media.getusermedia.microphone.off_while_disabled.enabled")
Screen-, app-, or windowsharing is not supported at this time.
On disabling, there's a delay before the device is ordered to stop. This is
now defaulting to 3 seconds but can be overriden by prefs
"media.getusermedia.camera.off_while_disabled.delay_ms" and
"media.getusermedia.microphone.off_while_disabled.delay_ms".
The delay is in place to prevent misuse by malicious sites. If a track is
re-enabled before the delay has passed, the device will not be touched until
another disable followed by the full delay happens.
MozReview-Commit-ID: D4nZWzrYZGm
--HG--
extra : rebase_source : 6a54fa450bd435ed65de2a30b66d25f4a5e8241e
This is the larger change for this bug. In order to turn off a device on
disabling we want to Stop() it without ending the attached track.
To allow this, this patch breaks out track-creation from Start() to SetTrack()
and moves track-ending logic from Stop() to Deallocate().
It is a programming error to Start() or Stop() a MediaEngineSource that hasn't
seen a SetTrack().
MozReview-Commit-ID: 3KzmuDjCAH0
--HG--
extra : rebase_source : 361d9b9c2a818ce51fa90d88950d5992c51407c6
The scope of flattening this hierarchy quickly grows large, so this patch does
a couple more things:
- Creates a pure interface MediaEngineSourceInterface and a base class
MediaEngineSource with common defaults and refcount support (no state!)
- Breaks out some of the helper classes to dedicated files, e.g.,
AllocationHandle, MediaEnginePrefs.
- Clarifies the threading model (written on one thread *and* under lock,
read under either)
- Fixes style, indentation, include-sorting in the affected files
- Adds comments, especially for clarifying what responsibilities methods have,
and thread usage of class members
- Changes Monitors to Mutexes since we only use them as Mutexes anyhow
- Makes MediaEngineRemoteVideoSource no longer a shared source since we now
support scaling in this source and CamerasChild can act as a broker of frames.
This greatly simplifies it. The only shared source is now
MediaEngineWebRTCMicrophoneSource, so the sharing specific common methods have
been moved to that source.
MozReview-Commit-ID: KeVZQo6gLm2
--HG--
rename : dom/media/webrtc/MediaEngine.h => dom/media/webrtc/MediaEnginePrefs.h
extra : rebase_source : c785a5feb896312912170475d6b8d997e712e48f
Currently we run the risk of missing MediaManager::OnNavigation() at shutdown in
some cases. When it happens, cleanup of window listeners is delayed to
MediaManager::Shutdown().
Triggering window listener shutdown through the destructor doesn't work when the
destructor is invoked by WindowTable::Clear(), as clearing out the
window listener's SourceListeners will trigger a call back into
WindowTable::Remove() to remove the now empty window listener.
This is not allowed by the hash table implementation.
This patch fixes this by changing strategy from cleanup-in-dtor to explicit-cleanup-before-dtor and making a non-clean state in the dtor an error.
MozReview-Commit-ID: C9FryVlv28d
--HG--
extra : rebase_source : 55ccf96b15eb3261d5176364e6952f51415bc668
This delays setting sInShutdown (renamed to sHasShutdown for better semantics)
until all that remains of shutdown is to shut down the media thread.
From JS this is no change as JS cannot run until Shutdown() is done.
The difference is that we let members and still-active listeners get destroyed
and cause any members that are media-thread only (in this case devices), to shut
down before the thread goes away.
MozReview-Commit-ID: 5NTWwh8Umn8
--HG--
extra : rebase_source : f6b508abc95434f027a6544fdac53949138764da
Dan Minor
Paul Adenot
Cosmin Sabou
Andreas Pehrson
Daniel Varga
Jan-Ivar Bruaroey
Csoregi Natalia
Sebastian Hengst
Alex Chronopoulos
Bogdan Tara
Andrea Marchesini
Haik Aftandilian
Mike Hommey
Brian Hackett
Boris Zbarsky
Margareta Eliza Balazs
Chris Pearce
Emilio Cobos Álvarez
Dorel Luca
Kyle Machulis
Andreas Pehrson
Bryce Van Dyk
Nathan Froyd
Matthew Gregan
Andreas Pehrson
Brindusan Cristian
Johann Hofmann
Munro Mengjue Chiang
Tom Ritter