1122798 - gUM(audio, video) reports success on devices with no camera (but with a microphone)

Status: RESOLVED DUPLICATE of bug 802326

(Core :: WebRTC: Audio/Video, defect, P3)

Description

[Nils Ohlmeier [:drno]]

If I request audio & video here: http://mozilla.github.io/webrtc-landing/gum_test.html
on a machine which has Audio hardware, but no camera attached, I get a door hanger for audio only (as expected) and then a Success! message on the screen, even though the request obviously can't give me a video stream.

According to https://w3c.github.io/mediacapture-main/#dom-mediadevices-getusermedia
 section 10.2.1 subclause 3, sub-subclause 4, sub-sub-subclause 2
this should result in a failure.

This also affects Firefox Hello, which allows me to create a conversation successfully. But when I share the link to that conversation with someone who then joins the conversation via the standalone client the call never gets established.

Comment 1

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

This is a logical conclusion of our user interface, which lets users choose what to share. We return back to the application what the user decided to share, which may be less than what the application asked for. If the user shared something, anything, then that's success.

The application can tell what it got by looking at stream.getVideoTracks() and stream.getAudioTracks() in the returned stream.

The practical difference between not having a camera and not granting a camera seems small, if we lean toward user-choice.

Our UI has always been this way, and I think the intent is to put the user in control. This does appear to deviate from the spec, as you point out, though it should be said that other browsers deviate in different ways to offer user-choice here (like letting users override what is being shared after-the-fact).

FWIW, applications can find out how many video and audio devices a user is in possession of using navigator.mediaDevices.enumerateDevices() (which we don't implement yet). 

I suggest you open a specific bug for Firefox Hello with expected behavior and actual behavior. It should be solvable with the existing gUM interface and the information here. 

I don't know if Firefox Hello allows a participant with audio-only to join a conversation, but leaning toward user-choice again, there's arguably value in Firefox Hello even for such as person, since, practically speaking there's little difference between allowing this and me turning on face-mute the second I join.

Comment 2

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

(In reply to Jan-Ivar Bruaroey [:jib] from comment #1)
> though it should be said that other browsers deviate in different ways to
> offer user-choice here (like letting users override what is being shared
> after-the-fact).

Whoops, this one part is wrong. After testing some other browsers more carefully, I have no evidence that they deviate from the spec here (changes only apply after refresh).

Comment 3

[Maire Reavy [:mreavy]]

Per discussion on Jan 30th, we don't want to fail getUserMedia() requests for video when we have no video device until we have ways for applications to determine if you have a camera (and we'd wait until this is available for "long enough" before enabling failure).  Until then, if you ask for video and have no camera, we'd return black or a "no-camera"/video-muted slate.