This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
If the device has no way to stream live video, the current algorithm sets finalSet to an empty set, asks the user agent to prompt the user on that set. Thus it's not clear whether: * the UA should prompt at all (I guess it could offer to stream a video file in that case) * whether it ends with "permission denied", or a stalled algorithm It would seem maybe more logical to trigger a ContraintNotSatisfied error, although it's not clear what the name of the constraint should be in that case (maybe the name of the requested media type?). (handling the absence of a media device differently is odd, since one could always get the same thing via a trivial mandatory constraint, e.g. video : { mandatory : {width: { min:0}}} )
To me it makes sense to trigger a ConstraintNotSatisfied error with the name of the media type that could not be supplied as name. I guess that if both audio and video is requested (audio: true and video: true), but none can be delivered, it does not really matter if audio or video is reported as constraintName.
I believe Firefox have implemented a non-standard NO_DEVICES_FOUND error for the case when no device for audio/video is available. I prefer this approach as I think a separate error would be better than conflating with the CONSTRAINT_NOT_SATISFIED error, which should only be for cases when a specific mandatory constraint cannot be met. Firefox also uses a non-standard HARDWARE_UNAVAILABLE error for when a device exists but for some reason cannot be used (such as, it is already in use by another web page/program). Thoughts?
I recently made a proposal for two new NavigatorUserMediaError error codes on the mailing list: http://lists.w3.org/Archives/Public/public-media-capture/2013Jul/0124.html They are: HARDWARE_UNAVAILABLE - A suitable device is connected but a hardware error prevented access (such as an OS/program/webpage lock) and NO_DEVICES_FOUND - No suitable devices are connected whatsoever This matches Firefox's current implementation, and I would like to see them formerly adopted into the spec. Also, perhaps all NavigatorUserMediaError error codes should use camelCase instead and inherit from DOMError, as ticket 22216 has requested: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22216
(In reply to comment #3) > Also, perhaps all NavigatorUserMediaError error codes should use camelCase > instead and inherit from DOMError, as ticket 22216 has requested: > https://www.w3.org/Bugs/Public/show_bug.cgi?id=22216 This is fixed and will be in the next release.
Suggested resolution, now that we inherit from DOMError: NO_DEVICES_FOUND -> NotFoundError (existing DOMError code) HARDWARE_UNAVAILABLE -> AbortError (existing DOMError code) -> SourceUnavailable (NEW DOMError code)
(In reply to comment #5) > Suggested resolution, now that we inherit from DOMError: > > NO_DEVICES_FOUND -> NotFoundError (existing DOMError code) > HARDWARE_UNAVAILABLE -> AbortError (existing DOMError code) > -> SourceUnavailable (NEW DOMError code) This seems very sensible. Thanks Harald.
FWIW, we're getting rid of DOMError: http://dom.spec.whatwg.org/#domerror
At the moment the comment says: "DOMError might be nuked in favor of using DOMException exclusively. See Creating your own errors on es-discuss for more details." DOMException seems to be numeric codes named with ALL_CAPS_WITH_UNDERSCORES. Are you going back to that naming style again? "There are two ways to do this. The deprecated one, and the one that doesn't work yet."
DOMException has a name field that returns the new-style name. However, we're still discussing with TC39 what the best way of error handling throughout the platform would be. (The editor of JavaScript actually favors a fairly minimalistic approach, without much branching on different types of exceptions and without introducing new ones.)
Now that we don't inherit from DOMError any more, since that's going away, but we still have an error object with a name and a message: Suggested change of names: NO_DEVICES_FOUND -> NotFoundError (existing DOMError name) HARDWARE_UNAVAILABLE -> AbortError (existing DOMError name) -> SourceUnavailable (NEW name) I'll create a new tracking error for the whole DOMError -> JS Error issue.
FIxed in version http://dev.w3.org/2011/webrtc/editor/archives/20140817/getusermedia.html