- From: Erin Spiceland <espiceland@digium.com>
- Date: Wed, 10 Jul 2013 10:11:19 -0500
- To: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Cc: public-media-capture@w3.org
On Wed, Jul 10, 2013 at 3:01 AM, Adam Bergkvist <adam.bergkvist@ericsson.com> wrote: > On 2013-07-09 19:16, cowwoc wrote: >> >> Hi, >> >> This is a follow-up discussion to >> https://code.google.com/p/chromium/issues/detail?id=257104 >> >> The WebRTC specification needs to provide a better error message in case >> the browser denies access to the camera, instead of the user. Currently, >> the specification states that PERMISSION_DENIED is the result of the >> user denying access. Instead of simply modifying the definition of >> PERMISSION_DENIED to cover both cases, I propose splitting it into >> separate cases: >> >> PERMISSION_DENIED_BY_USER >> PERMISSION_DENIED_BY_BROWSER >> >> Alternatively, we need to add a String error message alongside the enum, >> and require browsers to issue a different error message for each case. >> > > Will the browser ever deny permission without involving the user? I could > imagine some future scenario where a browser policy restricts the > browser/WebRTC from accessing certain cameras on a system, but wouldn't we > be fine with the same error as there is no camera (available) then? > The current behavior in Chrome is that if the user ever denies media on the call to getUserMedia, the browser will permanently block media and automatically deny subsequent requests, immediately calling the failure callback, without asking the user. I am not certain if the behavior is the same when using HTTPS. To unblock the site, the user has to go into Chrome's media preferences (chrome://settings/contentExceptions#media-stream) and remove the domain from the blocked list. -- Erin Spiceland, Senior Software Developer Digium, Inc., Huntsville, AL
Received on Wednesday, 10 July 2013 15:14:37 UTC