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
These were originally exposed directly as static methods on nsGlobalWindow, but
as they are clearly associated with either the inner or outer window, it makes
more sense for them to be called as such.
MozReview-Commit-ID: LFq8EfnhDlo
This is a large patch which tries to switch many of the external consumers of
nsGlobalWindow to instead use the new Inner or Outer variants.
MozReview-Commit-ID: 99648Lm46T5
The NS_LITERAL_STRING macro creates a temporary nsLiteralString to encapsulate the char16_t string literal and its length, but AssignLiteral() can determine the char16_t string literal's length at compile-time without nsLiteralString.
MozReview-Commit-ID: 6vgQiU8zN3o
--HG--
extra : rebase_source : 1b536b92ef43f610db057ace6f108620e8d8b4d5
extra : source : 336e21386d5eeb16f1c9893c29377f23b67cc4b0
XPCOM's string API doesn't have the notion of a "null string". But it does have
the notion of a "void string" (or "voided string"), and that's what these
functions are returning. So the names should reflect that.
--HG--
extra : rebase_source : 4e3f982e0873877174a08a25413595ff66f7d20e
Replace it with NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION, because it
has been the same for a while.
MozReview-Commit-ID: 5agRGFyUry1
--HG--
extra : rebase_source : 5388c56b2f6905c6ef969150f0c5b77bf247624d
As well as the obvious #ifdefs, this allows DOMHwMediaStream to be
removed, and also the "phone-state-changed" observer.
--HG--
extra : rebase_source : 373280183e228bd4b9bd9d866959409f2444c77e
Right before `MediaManager::EnumerateRawDevices` posts its enumeration
task to the background thread, add the option to send out a
"getUserMedia:ask-device-permission" notification, whose purpose is to
give frontend UI a chance to ask for device permissions (e.g. permission
to enumerate cameras on Android).
The subject parameter of the notification is an `nsIRunnable` task,
which is passed back to `MediaManager`, after receiving permission,
through the `getUserMedia:got-device-permission` notification. The
notification listener then posts the task and enumeration proceeds as
before.
MozReview-Commit-ID: IhRXTdIplvN
This in large does the following:
* Changes the model in MediaManager to align with that of chrome code, namely:
- One GetUserMediaWindowListener *per window*, containing N SourceListeners for N gUM requests, and
- GetUserMediaWindowListener replaces GetUserMediaStreamListener
- So if two SourceListeners stop we can still send only one event
* Breaks a special event specific to B2G chrome
MozReview-Commit-ID: 3wbPFmc9yWj
--HG--
extra : rebase_source : dff76a1fa604962b45446d632ffb4da58853cfa0
This in large does the following:
* Changes the model in MediaManager to align with that of chrome code, namely:
- One GetUserMediaWindowListener *per window*, containing N SourceListeners for N gUM requests, and
- GetUserMediaWindowListener replaces GetUserMediaStreamListener
- So if two SourceListeners stop we can still send only one event
* Breaks a special event specific to B2G chrome
MozReview-Commit-ID: 3wbPFmc9yWj
--HG--
extra : rebase_source : 4ad324f6bb1be637da584f323a3e039c5b4f664d
This in large does the following:
* Changes the model in MediaManager to align with that of chrome code, namely:
- One GetUserMediaWindowListener *per window*, containing N SourceListeners for N gUM requests, and
- GetUserMediaWindowListener replaces GetUserMediaStreamListener
- So if two SourceListeners stop we can still send only one event
* Breaks a special event specific to B2G chrome
MozReview-Commit-ID: 3wbPFmc9yWj
--HG--
extra : rebase_source : 4ad324f6bb1be637da584f323a3e039c5b4f664d
This patch removes support for mozapp iframes, leaving support for
mozbrowser iframes intact. Some of the code has been rewritten in order
to phrase things in terms of mozbrowser only, as opposed to mozbrowser
or app. In some places, code that was only useful with apps has been
completely removed, so that the APIs consumed can also be removed. In
some places where the notion of appId was bleeding out of this API, now
we use NO_APP_ID. Other notions of appId which were restricted to this
API have been removed.
This patch removes support for mozapp iframes, leaving support for
mozbrowser iframes intact. Some of the code has been rewritten in order
to phrase things in terms of mozbrowser only, as opposed to mozbrowser
or app. In some places, code that was only useful with apps has been
completely removed, so that the APIs consumed can also be removed. In
some places where the notion of appId was bleeding out of this API, now
we use NO_APP_ID. Other notions of appId which were restricted to this
API have been removed.
They are not unstoppable any longer. We just don't forward Stop() to the real source.
MozReview-Commit-ID: FdFccMsD3eb
--HG--
extra : rebase_source : e29a1abb8f2060cb72399d61d91ca3a00128f08c
MediaStreamTrack.remote is no longer part of the spec.
MozReview-Commit-ID: BgHJ1zNIoWN
--HG--
extra : rebase_source : 11022eb420cbdb0c7aa5aa7814cf35330f4170b9
If content stops multiple gUM tracks in the same event loop we should only
notify chrome once to avoid unnecessary chrome updates.
MozReview-Commit-ID: 93aAPUvydPt
--HG--
extra : rebase_source : 685a842acce4970df9a495af1d7fac267b3d252b
extra : source : ed8face75a4664fa11eb64c62a289adf5bcca6db