22251 2013-06-03 16:30:33 +0000 Define better error when no video or audio source is available 2014-08-25 07:40:22 +0000 1 1 1 Unclassified WebRTC Working Group Media Capture and Streams unspecified PC Linux RESOLVED FIXED P2 normal --- 25988 22217 1 dom harald adam.bergkvist annevk harald paul.neave public-media-capture stefan.lk.hakansson oldest_to_newest 88577 0 dom 2013-06-03 16:30:33 +0000 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}}} ) 88731 1 stefan.lk.hakansson 2013-06-05 12:38:04 +0000 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. 88732 2 paul.neave 2013-06-05 13:16:29 +0000 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? 91540 3 paul.neave 2013-08-02 09:10:44 +0000 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 92029 4 adam.bergkvist 2013-08-14 08:09:41 +0000 (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. 92408 5 harald 2013-08-21 11:34:14 +0000 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) 92410 6 paul.neave 2013-08-21 11:37:41 +0000 (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. 92419 7 annevk 2013-08-21 13:47:04 +0000 FWIW, we're getting rid of DOMError: http://dom.spec.whatwg.org/#domerror 92422 8 harald 2013-08-21 14:21:37 +0000 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." 92424 9 annevk 2013-08-21 14:43:54 +0000 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.) 102748 10 harald 2014-03-21 15:00:20 +0000 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. 110517 11 stefan.lk.hakansson 2014-08-25 07:40:22 +0000 FIxed in version http://dev.w3.org/2011/webrtc/editor/archives/20140817/getusermedia.html