If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

RESOLVED DUPLICATE of bug 802326

Status

()

Core
WebRTC: Audio/Video
P3
normal
Rank:
35
RESOLVED DUPLICATE of bug 802326
3 years ago
2 years ago

People

(Reporter: drno, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
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.
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.
Summary: gUM(audio, video) reports success on devices with no camera → gUM(audio, video) reports success on devices with no camera (but with a microphone)
(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).
(Reporter)

Updated

3 years ago
See Also: → bug 1124422
Depends on: 1046245
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.
Blocks: 1165687
backlog: --- → webRTC+
Rank: 35
Priority: -- → P3
Duplicate of this bug: 1125149
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 802326
You need to log in before you can comment on or make changes to this bug.