- From: Jan-Ivar Bruaroey <jib@mozilla.com>
- Date: Mon, 09 Dec 2013 09:51:37 -0500
- To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, Jim Barnett <Jim.Barnett@genesyslab.com>, Martin Thomson <martin.thomson@gmail.com>, "Cullen Jennings (fluffy)" <fluffy@cisco.com>
- CC: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>, Adam Bergkvist <adam.bergkvist@ericsson.com>
Thanks Stefan, I think that is a good assessment. .: Jan-Ivar :. On 12/8/13 7:38 AM, Stefan Håkansson LK wrote: > On 2013-12-05 16:05, Jim Barnett wrote: >> Stefan, My concern is whether the UA will know enough about the >> unsatisfied mandatory constraints to prompt the user intelligibly. >> Martin says that he doesn't think that the UA will be able to explain >> what the constraints mean. If that's the case, won't the user >> experience be pretty bad? "You do not have a device that satisfies >> this application's requirements. Please insert random objects into >> your USB slot and maybe something will work". > As others have said, the app would get the same info as today. The > difference would be that the user would know that the app asked to use > the camera. > > That said, I still think we have some experimenting to do to get to the > right models. The UA could for example display info in the doorhanger > ("no camera with sufficient resolution found"). That's why I think we > could consider leaving out the exact definition of the dialogue from the > spec (just put something like "in a UA specific way" in). > >> If we say that it's the app's job to explain what it needs, it will >> need to know which constraints weren't satisfied. That brings us >> back to the current definition of gUM (where the app finds out which >> constraints failed and then can decide whether to remove them and try >> again.) > Agreed, but it could do the same here, the difference would be that the > user would have been informed of the first attempt already. > > This also brings us back to the discussion on when the app should use > mandatory constraints with gUM: only when the app would rather skip > video (and/or audio) than not having those constraints met. This is what > we have been saying all along, and we've even said that using mandatory > constraints would be made more difficult. > > Always launching a permission prompt would perhaps enforce this - the > app developer would know that a prompt is launched even if there is a > mandatory constraint that can't be met, so the developer would likely be > careful and not put things that are not really mandatory as mandatory. > > I would agree to that we have some experimenting left to do in terms of > how to prompt, but perhaps that can be left to implementations? In the > same way as the current consent prompting is. > >> - Jim >> >> -----Original Message----- From: Stefan Håkansson LK >> [mailto:stefan.lk.hakansson@ericsson.com] Sent: Thursday, December >> 05, 2013 4:48 AM To: Jim Barnett; Martin Thomson; Cullen Jennings >> (fluffy) Cc: Silvia Pfeiffer; public-media-capture@w3.org; Adam >> Bergkvist Subject: Re: Bug 23934 - Proposal: Always launch permission >> prompt to avoid leakage >> >> I think my views are quite similar to Martin's. >> >> I think that perhaps we could leave a lot of this up to >> implementations (e.g. what kind of info is displayed if no device >> that meets the mandatory constraints is available). For the case were >> suitable devices are found, the current draft says "Prompt the user >> in a user agent specific manner for permission...". We can use >> similar phrasing for cases when no devices that meet mandatory >> constraints are found. >> >> On 2013-12-03 18:11, Jim Barnett wrote: >>> I'm trying to understand the proposal better, and have a couple of >>> questions: >>> >>> 1. In the case where one or more devices meet the mandatory >>> constraints, are they the only ones that are presented to the >>> user? >> This question is not related to the "Always launch permission >> prompt" proposal per se, it is related to mandatory constraints used >> with gUM. >> >> It is something we need to agree on; and the first level we need to >> agree on is whether this must be specified or can be left to the UA >> to decide. >> >> >>> 2. In the case where no device meets the mandatory constraints, do >>> we assume that the UA can explain the constraints clearly enough so >>> that the user can tell what sort of device is needed? >> Perhaps we do not need to spec this, perhaps something like "Inform >> the user in a user agent specific manner that the page asked for >> access to cameras/microphones but that no devices that met the >> requirements were found." is enough. >> >>> 3. In the case where no device meets the constraints, do we present >>> a list of all attached devices to the user? Would we let him >>> select a microphone when the app has asked for a camera? >> Of course not. The first level of constraints with gUM is "audio" or >> "video", and you can't use one in place of the other. >> >>> - Jim >>> >>> -----Original Message----- From: Martin Thomson >>> [mailto:martin.thomson@gmail.com] Sent: Tuesday, December 03, 2013 >>> 12:01 PM To: Cullen Jennings (fluffy) Cc: Silvia Pfeiffer; Stefan >>> Hakansson LK; public-media-capture@w3.org; Jim Barnett; Adam >>> Bergkvist Subject: Re: Bug 23934 - Proposal: Always launch >>> permission prompt to avoid leakage >>> >>> On 3 December 2013 08:57, Cullen Jennings (fluffy) >>> <fluffy@cisco.com> wrote: >>>> The question is what happened when none of the devices meet the >>>> constraints. Do you pop a dialog up to the user that says "Hey, >>>> your web page wanted to something that they can not have. Wait >>>> some random amount of time before deciding to click OK to dismiss >>>> this dialog". >>> You are right, that is the question. >>> >>> That's an implementation choice as far as I'm concerned. The site >>> isn't going to get an answer, so I'm not sure that there is much >>> point in asking a user, but I'm of the opinion that a user should >>> be able to make the choice still. Maybe the "choice" involves >>> plugging a device in that does meet constraints.
Received on Monday, 9 December 2013 14:52:06 UTC