Re: NavigatorUserMediaError - numeric?

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