Closed Bug 1125149 Opened 9 years ago Closed 9 years ago

Firefox implementation of getUserMedia non-compliant with standard

Categories

(Core :: WebRTC, defect)

35 Branch
x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1122798
backlog parking-lot

People

(Reporter: adrian.wilkins, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20150112203352

Steps to reproduce:

See : https://code.google.com/p/chromium/issues/detail?id=450549

1. Using a machine that has a microphone, but not a webcam
2. Visit a WebRTC site like http://appear.in or http://talky.io
3. Start a session



Actual results:

1. Prompted for media access permissions
2. Application works


Expected results:

1. Application should respond "couldn't get access to your camera and microphone" (the way they are written right now anyway).

Yes, it's counter-intuitive. I'm complaining about something just working.

The problem is that Firefox implementation deviates from the contract for getUserMedia ( http://w3c.github.io/mediacapture-main/#dom-mediadevices-getusermedia ) . Sites that implement WebRTC session initiation are implementing what works on Firefox and neglecting to catch MediaStreamError with a name of NotFoundError and try again with fewer items in requestedMediaTypes.

This means those sites break in Chrom(ium|e) when you have no camera. This is bad for overall WebRTC adoption ; if it's selling point is that it's available to anyone with a mainstream browser, differences in behaviour are bad.

I'm just a user though! Please refer to the Chromium guys if you want to have a technical debate about it...
Component: Untriaged → WebRTC
Product: Firefox → Core
with constraints for video set True,and camera disabled getUserMedia results in succes CallBack which is a incorrect behaviour(Chrome results in Error CallBack) and this is a bug on firefox browser.

getUserMedia({audio:true, video:true}, gotStream, logError);

function gotStream(stream) {

   //succes CallBack

}

function logError(error) {

   log(error.name );

}
Jib -- Can you recap the argument for why we do this?
Status: UNCONFIRMED → NEW
backlog: --- → parking-lot
Ever confirmed: true
Flags: needinfo?(jib)
See bug 1122798.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(jib)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.