This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 22211 - getUserMedia algorithm and unrecognized requestedMediaTypes
Summary: getUserMedia algorithm and unrecognized requestedMediaTypes
Status: RESOLVED FIXED
Alias: None
Product: WebRTC Working Group
Classification: Unclassified
Component: Media Capture and Streams (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: public-media-capture@w3.org
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-30 12:06 UTC by Dominique Hazael-Massieux
Modified: 2013-08-27 08:55 UTC (History)
3 users (show)

See Also:

Attachments

Description Dominique Hazael-Massieux 2013-05-30 12:06:33 UTC 
the getUserMedia algorithm doesn't explicitly abort if none of the requestedMediaTypes in the constraints dictionary are recognized (or likewise if constraints is the empty dictionary).

The current algorithm implies that the successcallback should be triggered with a MediaStream with no tracks — is that really what we want?

from what I can tell, it used to be that a not supported exception was to be thrown; I think it probably ought to invoke the error callback with a not supported error.
Comment 1 Adam Bergkvist 2013-06-04 13:15:02 UTC 
I think it's ok to create a stream with no tracks with the MediaStream() constructor, but to get one from getUserMedia() seems more like an error. I agree with dom's reasoning.
Comment 2 Harald Alvestrand 2013-08-27 08:55:09 UTC 
Resolved in 20130824 version of MediaCapture.