W3C home > Mailing lists > Public > public-media-capture@w3.org > August 2012

Re: NavigatorUserMediaError - numeric?

From: Paul Neave <paul.neave@gmail.com>
Date: Wed, 29 Aug 2012 17:09:20 +0100
To: Harald Alvestrand <harald@alvestrand.no>
Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <9C7331216D734E9FBB88A7FD45167380@gmail.com>
What's the progress on adding two more types to the spec (enum strings or otherwise)?

A while ago Marcin Simonides from Opera suggested that we add the following:


PERMISSION_DENIED has to be presented to let developers handle this event
and it's a good idea to let them re-ask the access again if user denied it
accidentally. Probably it's already implemented in this way.

NOT_SUPPORTED_ERR sounds like reasonable event for the case when there are
no audio/video recording devices at all.

DEVICE_NOT_AVAILABLE could be a good event for the case when device is
presented, but by some reason is unavailable while access request.




>From my experience so far with the getUserMedia API, these two extra constants are badly needed to improve the user experience, as currently PERMISSION_DENIED is not an accurate error if the user does not own a compatible device.

Paul.



On Wednesday, 22 August 2012 at 13:21, Harald Alvestrand wrote:

> Hello,
> 
> some time back, an effort was done to get rid of most cases of numeric 
> codes from the specs, and replace them with enumerations of strings.
> 
> We have one left:
> 
> [NoInterfaceObject]
> interface NavigatorUserMediaError {
> const unsigned short PERMISSION_DENIED = 1;
> readonly attribute unsigned short code;
> };
> 
> Is there any reason this shouldn't be an enum with the single value 
> "permission denied"?
> 
> Harald 
Received on Wednesday, 29 August 2012 16:09:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:11 UTC