This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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.
Resolved in 20130824 version of MediaCapture.