Closed Bug 1125149 Opened 10 years ago Closed 10 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)
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(jib)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.