Re: [Bug 22337] When does the light come on?

The "light" (or whatever the indicator is), should be on when capturing. There should be a way for the JS application to pause capture in a way that both causes the light to go out and allows easy resumption of capture. There might be a nuance of this in that it takes the light a second to go off to avoid flicker capture attacks.

Users find if  troublesome when the light is always on even when it is not capturing.  Applications that leave the light on all the time get lots of user complaints and typically change to not cause the light to be on when they are not capturing. Leaving the light on all the time causes users to start ignoring the light which is also bad. 


On Mar 22, 2014, at 1:29 AM, bugzilla@jessica.w3.org wrote:

> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22337
> 
> Randell Jesup <rjesup@jesup.org> changed:
> 
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                 CC|                            |rjesup@jesup.org
> 
> --- Comment #2 from Randell Jesup <rjesup@jesup.org> ---
> (In reply to Harald Alvestrand from comment #1)
>> The current text on indicators is:
>> 
>> - 4.3 says that when a track is stopped, the user agent should remove the
>> indicator for that source.
>> 
>> - 10.1.1 says that UAs are encouraged to include a prominent indicator that
>> the devices are "hot" when getUserMedia returns successfully
>> 
>> I think this is pretty precise (although one can discuss whether it is
>> sufficient). It does allow one to do the "indicator flash" thing where one
>> opens up a device, takes a photo and closes the device immediately - but
>> leaving the indicator on when no media is being captured seems lame.
> 
> One can leave this up to the UA; on FxOS (and maybe android, I forget) we dim
> it after ending, and then let it time out shortly.  The indicator flash concern
> is mostly around uses with persistent permission OR with implementations that
> allow a single permission to make a camera go "hot" multiple times (which I
> consider a major privacy risk) AND don't require the indicator be on the entire
> time permission is given (see below).
> 
>> We don't have any requirement that an indicator be shown when permission is
>> granted. If we want that, I think we need an additional indicator, not the
>> "on-air" one.
> 
> Actually, it's arguable what the current spec requires - the text is 
> 
> "If the user grants permission to use local recording devices, user agents are
> encouraged to include a prominent indicator that the devices are "hot" (i.e. an
> "on-air" or "recording" indicator)."
> 
> There's no "when recording starts" or "when the devices are 'hot'" (it uses
> "that", which changes the meaning considerably compared to "when"; you
> certainly can read the text as "you need to put up an indicator once the user
> grants permission".
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.
> 
>

Received on Thursday, 27 March 2014 20:16:52 UTC