More UserMediaError codes (Re: NavigatorUserMediaError - numeric?)

On 08/29/2012 06:09 PM, Paul Neave wrote:
> 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:
I found this note in the WebRTC WG archive from May 2012, so it's a 
while ago.... thanks for bringing it back!

I have created [ACTION-9] to track this issue, and provisionally 
assigned it to me.

The concern I've seen raised before with detailed error messages is that 
it allows probing to identify the user (you probe for a camera that he 
might or might not have), but information about whether the user or the 
system rejected the call is easily visible from timing anyway, so 
returning an error might be good for the Good Guys while not giving 
anything new to the Bad Guys.

So I make it

"permission denied" - user said no
"not available" - there is a device, but it is doing something else
"not supported" - no device satisfies the constraints

What do others think?

                Harald


>
>
> 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:30:04 UTC