- From: Rob Manson <roBman@mob-labs.com>
- Date: Fri, 26 Jul 2013 09:43:47 +1000
- To: public-webrtc@w3.org
+1 to that (as long as DEVICE_NOT_AVAILABLE includes both system errors and truly "not available" so it doesn't provide a fingerprinting issue). Also, thanks for pointing out where the PERMISSION_DENIED came from Silvia 8) I was looking in the wrong spec (must have been tired). So in this case the bug should be filed with Chrome and not Firefox. From my tests the latest version of Chrome doesn't return PERMISSION_DENIED. As for your question: "JS can react and read what constraints the device supports (do we have such an API??)" There's: MediaStreamTrack.capabilities() Returns a dictionary with all of the capabilities for the track type. 6. Source capabilities Each constraint that is supported by an implementation MUST have an associated capability that will be returned in the result of a call to the capabilities() method. ... e.g. dictionary AllVideoCapabilities { CapabilityList? sourceType; CapabilityList? sourceId; CapabilityRange? width; CapabilityRange? height; CapabilityRange? frameRate; CapabilityList? facingMode; }; and MediaStreamTrack.states() Returns an object containing all the state variables associated with the allowed constraints. 5. Source states ... In the same way that the current set of constraints can be returned on a track using the constraints() method, the states() method on a track returns the values of the state variables associated with all capabilities, as the MediaSourceStates object. ... e.g. dictionary MediaSourceStates { SourceTypeEnum sourceType; DOMString sourceId; unsigned long? width; unsigned long? height; float? frameRate; VideoFacingModeEnum? facingMode; unsigned long? volume; }; I need to do some more testing to clearly understand how these relate to each other, especially in the error conditions as in this case the MediaStream and therefore it's MediaStreamTrack's are not available so I assume these will simply not be able to be used. However, Firefox and Chrome haven't implemented these MST methods yet. roBman On 26/07/13 08:17, Silvia Pfeiffer wrote: > On Fri, Jul 26, 2013 at 1:51 AM, cowwoc <cowwoc@bbs.darktech.org> wrote: >> >> I think there is a misunderstanding of the issue. I am asking to >> differentiate between: >> >> * Access denied by the user (whether directly or by way of a saved preference) > > Looking at http://dev.w3.org/2011/webrtc/editor/getusermedia.html#idl-def-NavigatorUserMediaError, > that's the error message PERMISSION_DENIED > >> * Access denied by the browser > > and this would be CONSTRAINT_NOT_SATISFIED - or wouldn't it? > > >> The former is recoverable. The latter is fatal (likely a programming >> bug). >> >> I am *not* asking to differentiate between a user denying access >> directly versus denying access by way of a saved preference. > > PERMISSION_DENIED_USER and PERMISSION_DENIED_BROWSER don't seem the > right choice of names then. > > Maybe you can specify more clearly what case you'd like flagged that > is different from CONSTRAINT_NOT_SATISFIED ? > > > Is it e.g. something like DEVICE_NOT_AVAILABLE ? Then I could imagine > the browser going: > > 1. Did the user (at some stage) disallow me to access the device? > Yes: flag PERMISSION_DENIED error > -> JS can react and bring up informative dialog > (I'd actually prefer that to the browser bringing up the dialog - > maybe there should be a way to ask the browser not to bring up the > dialog?) > No: proceed > > 2. Can I get to the device? > No: flag DEVICE_NOT_AVAILABLE error > -> JS can react and bring up a dialog telling the user to check > the camera connection > Yes: proceed > > 3. Can I get the stream from the device with the given constraints? > No: flag CONSTRAINT_NOT_SATISFIED error > -> JS can react and read what constraints the device supports (do > we have such an API??) or at least try a different constraint set > Yes: proceed > > > Cheers, > Silvia. > >
Received on Thursday, 25 July 2013 23:44:16 UTC