828600 - [camera] Recording icon shows in status bar even when no video recording is happening

Status: RESOLVED DUPLICATE of bug 898917

(Firefox OS Graveyard :: Gaia::System, defect, P1)

Description

[Marcia Knous [:marcia]]

Attachment: Screenshot of issue

Gecko: 13695ef9e8f6
Gaia: 3808444b9923

STR:
1. From the lockscreen, swipe to the camera and begin a video recording
2. Hit the home button and then go back into the device using the lock icon.
3. Observe attached screenshot

Recording icon still shows, but the video is not recording when you go back into the camera app. See attached screenshot

Comment 1

[Marcia Knous [:marcia]]

Attachment: Screenshot of issue

Comment 2

[Sotaro Ikeda [:sotaro]]

The problem appear when Camera app is loaded in chrome process. And after when bug 833521 is fixed. The problem happens always in Camera app.

I confirmed that 'recording-status' event is correctly delivered to statusbar.js in System App.

Comment 3

[Sotaro Ikeda [:sotaro]]

(In reply to Sotaro Ikeda [:sotaro] from comment #2)
> The problem appear when Camera app is loaded in chrome process. And after
> when bug 833521 is fixed. The problem happens always in Camera app.

> statusbar.js in System App.

correction:
And after when bug 833521 is fixed, the problem becomes to always happen in Camera app.

Comment 5

[Aaron Train [:aaronmt]]

I hit this bug today on b2g18-unagi-(01/30), reproducible.

Comment 7

[Andrew Overholt [:overholt]]

Moving the tef? from bug 836474.

Comment 8

[David Scravaglieri [:scravag]]

We would track it until a patch information about risk is provided

Comment 9

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

hit this today as well on unagi/otoro

Gecko  http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_0/rev/361d9359f4f3
Gaia   0abc95774d0bbdfe314fa588e09fc92cac3e6427
BuildID 20130130113326
Version 18.0
Unagi

Comment 10

[Lukas Blakk [:lsblakk] use ?needinfo]

Not blocker, tracking as per comment 8.

Comment 11

[Dale Harvey (:daleharvey)]

Not seeing status-recording events at all, filed a new bug.

Comment 12

[Dale Harvey (:daleharvey)]

We have a seperate active / inactive icon and show the inactive one for 60 seconds once we stop recording, this is by design

Comment 13

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

I just ran into this too and found this bug as a duplicate.

On the Uniagi with a v1 build, the camera app stops recording as soon as you exit the app by hitting the home button. If that is correct behaviour then what is the point of confusing the user by showing a red dot (which universally means 'we are recording') in the status bar?

Comment 14

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Not sure the point of having an inactive red icon in the status bar.  Camera app is still running in the background process.  Is the camera app still doing something during the time we have the red dot?  ie processing preview images?  If not, I think it's confusing to the user.  CC'ing UX

Comment 15

[Patryk Adamczyk [:patryk] UX]

This is more an interaction question, but I have to agree with Naoki, if the camera is not recording the icon should disappear, unless the recording has been paused. Casey could clarify the design intent here.

Comment 16

[Casey Yee]

This is by design.  The timeout is there so that in the case of a picture or short video that the user doesn't miss that the camera was active.

As per the bug, this could be a little confusing to the user.   To solve this we could apply some extra logic:

- The indicator should show for a minimum of [x] seconds for photos or short videos below a [x] seconds.
- If a video is recorded that is over [x] seconds the indicator should disappear immediately after video recording is stopped.

x = 3 seconds would be a good start.

Comment 17

[Octavian Damiean [:mainerror]]

To be honest, I don't see how that would communicate the right message.

I ran into it as well today and thought the camera would still be recording in the background somehow.

If the camera isn't recording anymore, the icon should disappear. As a user I don't see why I would care if the camera was active because I know it was active, I was the one recording after all.

Comment 18

[Marcia Knous [:marcia]]

I am reopening this bug - we talked about this in the QA area with some engineers and the consenus was we don't think it makes sense to show the dot for so long after recording is stopped.

On Leo device using the latest build the red dot is never going away.

Comment 19

[Bob Moss :bmoss]

If the intent of this is to indicate to the user that the camera has been active, then I would propose that you use a different icon. As has been previously stated a red circle is pretty universal as the "I am recording" indicator. Also there doesn't seem to be a time out associated with this indicator so even if the indicator is correct behavior, it's not going away is the bug.

Comment 20

[Alex Keybl [:akeybl]]

(In reply to Marcia Knous [:marcia] from comment #18)
> On Leo device using the latest build the red dot is never going away.

Can we open up a new bug for this? Never disappearing is a different bug (implementation) than this one, where people didn't like that it disappears after 3 seconds (design).

Comment 21

[Mike Habicher [:mikeh] (high bugzilla latency)]

(In reply to Bob Moss :bmoss from comment #19)
>
> If the intent of this is to indicate to the user that the camera has been
> active, then I would propose that you use a different icon. As has been
> previously stated a red circle is pretty universal as the "I am recording"
> indicator. Also there doesn't seem to be a time out associated with this
> indicator so even if the indicator is correct behavior, it's not going away
> is the bug.

The "I am recording" icon is a red circle in the status bar; the "I have recently been recording" icon is a grey circle in the status bar that is supposed to timeout/disappear after 60 seconds. (Personally, I like the idea of an indicator of recent recording activity, but will admit that the grey icon is occasionally confusing.)

(In reply to Marcia Knous [:marcia] from comment #18)
> 
> On Leo device using the latest build the red dot is never going away.

I've seen this as well on unagi and it's a regression.

Comment 22

[Dale Harvey (:daleharvey)]

It is probably worth mentioning that the 'recording' indicator will never actually be seen active when using the Camera app normally as it is in full screen, so when you close the camera after recording you only see the inactive icon (which is still red, just less bright)

If the icon never dissapears then that is a definite bug, I havent seen it / cant reproduce though, unassigning myself since the assignment was left over from last time and not sure what is getting fixed here

Comment 23

[Stephany Wilkes]

Just to be clear: Is the bug (per comment 18) that "the red icon appears when recording is not actually in progress" and/or that "the red icon in fact appears all the time no matter what is going on?" 

And the need here is for UX to clarify the precise meaning and behavior of the red icon? Trying to close out this thread. Thanks all!

Comment 24

[Marcia Knous [:marcia]]

The red icon showing all the time is a Leo bug I have to file.

The bug in my mind is the red icon still shows when recording is stopped.

(In reply to Stephany Wilkes from comment #23)
> Just to be clear: Is the bug (per comment 18) that "the red icon appears
> when recording is not actually in progress" and/or that "the red icon in
> fact appears all the time no matter what is going on?" 
> 
> And the need here is for UX to clarify the precise meaning and behavior of
> the red icon? Trying to close out this thread. Thanks all!

Comment 25

[Stephany Wilkes]

Casey, can you please confirm when exactly the red dot should and should not be shown?

Comment 26

[Casey Yee]

The red dot should be displayed whenever the video recorder is started.   It should also persist for a certain amount of time after the recording has stopped so that the user is aware that a recording has happened.  It doesn't have to be long, just a few seconds.     It also shouldn't be too long otherwise it will confuse users (as per this bug).

The intent here is to prevent applications from recording short bursts of video (< a few seconds) without the users knowledge.

Comment 28

[Paul Theriault [:pauljt] (no longer reading bugmail)]

I think we need a notification in the notification center to explain what app is recording (or was just recording). This is going to be increasingly important when this (or similar) notification UI is used as a security mitigation for WebRTC.

Any thoughts on this from a UX perspective? 

I am imagining something like what we do for Firefox on android. (see 874401)

From a security perspective we need:
- some way to tell the user what app is recording
- what device is being used (microphone or camera)
- ideally something they can do about it (e.g. for active recording, tap the notification to focus the app using the API, or for the notification of recent recording)

Thoughts?

Comment 29

[Stephany Wilkes]

Assigning needinfo to Rob and clearing the request for Casey since camera is Rob's domain.

Comment 30

[Stephany Wilkes]

Reassigning to general FFOS UX identity since Esther is working on specs in this area now.

Comment 31

[Darren]

The issue is occurring on build: 20130625070217
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/29933d1937db
Gaia: 1436e2778b90bd74635b0b94d1cf8ccb0d71b60c

When recording and switching to the homescreen the icon appears and after closing the app the icon still appears.

Comment 33

[Casey Yee]

(In reply to Paul Theriault [:pauljt] from comment #28)
> I think we need a notification in the notification center to explain what
> app is recording (or was just recording). This is going to be increasingly
> important when this (or similar) notification UI is used as a security
> mitigation for WebRTC.
> 
> Any thoughts on this from a UX perspective? 
> 
> I am imagining something like what we do for Firefox on android. (see 874401)
> 
> From a security perspective we need:
> - some way to tell the user what app is recording
> - what device is being used (microphone or camera)
> - ideally something they can do about it (e.g. for active recording, tap the
> notification to focus the app using the API, or for the notification of
> recent recording)
> 
> Thoughts?


I would propose that only foreground applications should be able to record video/audio/photos.   If the home-button is pressed or if the user switches out to another application, access to the video/audio/photos capabilities should be shut down along with it.   With this policy there should never be any confusion of which app is actively capturing video/audio/photos data.

Secondly, for any half-decent (legitimate) application, it should be quite obvious to the user when the app is capturing camera/audio/photo in it's UI.   Even if it wasn't, the app still needs to request explicit permission to do so before any capturing begins.   If for example a sudoku game inexplicably requests access to the camera features for no obvious use, this should immediately raise a red-flag to the user as to it's purpose for requesting access to these features.   

The red-dot adds another layer of information for the user so that if despite everything else that the user should be aware that a application has captured video/audio/photo data of some sort.   It's main purpose is to make users aware that a capture has happened and not necessarily the type of capture and help users identify any malicious or unexpected use of the video/audio/photo recording features.

If there is any confusion of what the red dots purpose is, i think it's probably because of how long it ends up showing for in the status bar.   We need to dial this down to a maximum of 2 or 3 seconds after recording has stopped otherwise people will be confused as to the meaning of the indicator.  

Having said all that,  I absolutely recognize that this may not be the best solution and am open to any suggestions on how we may be able to make this more clear for the user.


(In reply to Dale Harvey (:daleharvey) from comment #22)
> It is probably worth mentioning that the 'recording' indicator will never
> actually be seen active when using the Camera app normally as it is in full
> screen, so when you close the camera after recording you only see the
> inactive icon (which is still red, just less bright)

This is certainly a known issue.  I'm not sure what we can do about this without disturbing the apps UX.   We will definitely need to think about how important it is to show the recording indicator in the full-screen scenario and if we even feel that it's necessary to do so.  

Here are some options off the top of my head:
1. Always show the recording indicator (even if it disrepute the apps UX).  Just make it small and low-profile enough to be mostly out of the way.
2. Show the recording indicator if there is no element rendering the live output and hide the recording indicator if there is live view output (like in camera app).
3. Warn users that apps in full-screen mode may record audio/video.
4. Some kind of configurable audio alert that recording has started/stopped.

Comment 34

[Stephany Wilkes]

In an effort to move this bug along a bit more quickly, UX is going to review Casey's recommendations, create a spec of our recommendation, and attach it to this bug. In the meantime, security should also evaluate Casey's proposals and note which (if any) work best for them, and we can take those into account during spec creation.

Comment 35

[Dale Harvey (:daleharvey)]

There is a 5th option to have parity with other mobile OS's and assume that applications that are recording video (a privileged API the user has already agreed to) are responsible for showing their own UI for the status of the recording to the user.

Comment 36

[Chris Kreinbring [:CKreinbring]]

Still repros on Leo 1.1 commercial RIL.

Build ID: 20130715070218
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/6062fdf2deb8
Gaia: 55ed5e08a2250ea2d3571fff860c39e66fabed14
Platform Version: 18.1
RIL Version: 01.01.00.019.158

Comment 40

[Viga]

Any update on this bug?

Comment 42

[DingYu]

Is this bug fixed?

Comment 43

[Stephany Wilkes]

Flagging Maire and Ivan to see if they may know if this bug has been fixed, and/or have additional input based on specs being circulate.

Comment 44

[Maire Reavy [:mreavy]]

I believe this bug is about the camera app, not the browser or webrtc.  I think someone from the Gaia team will have this info.  My understanding is that Ivan is reaching out to the Gaia team to get this info and will reply on this bug with that info soon (by tomorrow).

Comment 45

[Jack Liu]

Dears, the indicator confuse users, they may think camera is still working.

Comment 46

[Preeti Raghunath(:Preeti)]

Shipped in 1.0.1 so don't see how this is a blocker. I'd prefer moving this to 1.2.

Comment 47

[Ivan Tsay (:ITsay)]

(In reply to Stephany Wilkes from comment #43)
> Flagging Maire and Ivan to see if they may know if this bug has been fixed,
> and/or have additional input based on specs being circulate.

(In reply to Maire Reavy [:mreavy] from comment #44)
> I believe this bug is about the camera app, not the browser or webrtc.  I
> think someone from the Gaia team will have this info.  My understanding is
> that Ivan is reaching out to the Gaia team to get this info and will reply
> on this bug with that info soon (by tomorrow).

I think this belong to Camera not in media recording. Need info from Media EMP

Comment 48

[Hema Koka [:hema]]

Stephany,

In comment 34, you mention that Ux is working on a spec with recommendations. Do we have that ready?

Thanks
Hema

Comment 49

[Jason Smith [:jsmith]]

This is confirmed to also affect getUserMedia, which is highly problematic. This means we're communicating a lie to the user of when the recording is active vs. not - in fact, the recording indicator is overly aggressively showing when recording is active. On FxAndroid, similar issues like these impacted privacy, as we send the user perception that recording is active, when in fact, it isn't.

Monica - What's your take on the severity of getting this fixed for enabling getUserMedia on Firefox OS in 1.2?

Comment 50

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #49)
> This is confirmed to also affect getUserMedia, which is highly problematic.
> This means we're communicating a lie to the user of when the recording is
> active vs. not - in fact, the recording indicator is overly aggressively
> showing when recording is active. On FxAndroid, similar issues like these
> impacted privacy, as we send the user perception that recording is active,
> when in fact, it isn't.
> 
> Monica - What's your take on the severity of getting this fixed for enabling
> getUserMedia on Firefox OS in 1.2?

Meant to say - overly aggressively showing when recording is inactive

Comment 51

[Jason Smith [:jsmith]]

Actually, nevermind - I think it's already clear that this is going some significant privacy concerns if this isn't fixed for gUM.

Comment 52

[lecky]

Is this issue can be solved in V1.1?

Thanks.

Comment 53

[lecky]

Hi Beatriz Rodriguez,

This issue would not be solved on V1.1HD, Do you accept it?

Thanks

Comment 54

[Beatriz Rodríguez [:brg]]

Which is the progress to fix this issue in v1.2? Many partners had expressed their desired to have a fix for the bug, is it feasible to include it in v1.2 scope?

Comment 55

[Aaron Train [:aaronmt]]

Still see this issue in 1.2 builds

Comment 56

[Sandip Kamat]

I am adding comments from FxOS Product mgmt perspective: This bug needs to be fixed for 1.2. 

This will be used by 3rd party recording/dictation apps and developers/partners would cause the same concerns as listed in this thread. 

I agree with Casey's proposal in comment#33 for these points:
1. Only foreground apps should have full recording access 
2. Apps should request an explicit permission from the user before recoding them.

I also want to add a comment to explore if we can change that "informative icon" itself. Red dot is pretty universal for "recording NOW". so icon for "Recording happened" should be something else. (Maybe something along the lines of attention seeking, with "!" etc but will leave that to the UX experts).

Comment 57

[Stephany Wilkes]

This work was covered in the spec that Esther did, and that Jacqueline finished, for Media Recording. It doesn't matter what team something should or should not be in at this point: This work was done, months ago, as part of Media Recording specs. UX has made its recommendation many times. Casey's recommendations from earlier in this thread, as far as I can tell, included in these specs.

The spec is here:
https://mozilla.box.com/s/452e7nr7e8p06ea3uuvh

Discussion on implementation is here (which is also linked to in a comment attached to the spec):
https://etherpad.mozilla.org/b2g-gum-ux-feedback

I have flagged ni? jsmith as he should be able to clarify (or point anyone to the people who can clarify) any differences between the implementation and the UX design.

I do not know what more UX can do at this point. What else is needed here?

Comment 58

[Stephany Wilkes]

This work was covered in the spec that Esther did, and that Jacqueline finished, for Media Recording. It doesn't matter what team something should or should not be in at this point: This work was done, months ago, as part of Media Recording specs. UX has made its recommendation many times. Casey's recommendations from earlier in this thread, as far as I can tell, included in these specs.

The spec is here:
https://mozilla.box.com/s/452e7nr7e8p06ea3uuvh

Discussion on implementation is here (which is also linked to in a comment attached to the spec):
https://etherpad.mozilla.org/b2g-gum-ux-feedback

I have flagged ni? jsmith as he should be able to clarify (or point anyone to the people who can clarify) any differences between the implementation and the UX design.

I do not know what more UX can do at this point. What else is needed here?

Comment 59

[Jason Smith [:jsmith]]

Wrote up an email to UX about this, but I'm going give a summary here on what I think we should do.

1. Leo cites a bug in bug 898917 that is likely causing the heavy pushback here - we're persisting the recording indicator for one minute rather than a few seconds, which UX is currently suggesting. That will resolve most of the concerns on this bug. In favor avoiding more confusion on this bug, I'm going to dupe to that bug and ask Tim to review leo's patch.

2. I'm splitting out the getUserMedia concern into a separate bug - in gUM's case, we don't need to persist a recording indicator post recording, because the short burst recording use case Casey cites isn't possible, as a prompt and user acceptance is required before recording can start.

3. We need to address three additional open questions here which is being discussed over email:
* Can recording in the camera app with mozCameras start while the camera app is in the background?
* Why was mozCameras implemented to allow by default in a certified app, rather than prompt?
* Can UX figure out a way to distinguish recording now vs. recording in the past such that it avoids user confusion?

Comment 60

[Jacqueline Savory [:jsavory] UX]

The red dot icon should not display for an extra minute as it is very confusing for the user and doesn't help the core use case of the red dot, which is to know if recording is currently taking place. 

Instead, the idea of having the icon gradually dim or fade idea could be helpful with allowing the user to realize that recording did take place or has just finished. However, this should only be apparent for about 3 seconds after recording has finished, or if this is not possible for some reason then the red dot should disappear when recording ends. I feel that the user needs to be able to refer to the red dot to understand if recording is currently taking place or not. 

Let me know if more detail is needed.

Comment 61

[Mike Habicher [:mikeh] (high bugzilla latency)]

Regarding comment 60, my understanding of the current intended implementation is that the recording icon is supposed to turn grey and persist for a few seconds after video recording ends, then disappear. It is only supposed to stay red while video recording is taking place. Any other behaviour is a bug that needs to be fixed.

The current implementation does _not_ correctly handle the case where the Camera app is killed, since the recording-stop event is only sent to the parent process when stopRecording() is called.

Regards comment 59, question 3:
a. yes: the API doesn't know if the app using it is in the background, it only cares that the app has permission.
b. it was deemed unacceptable to prompt the user of the certified Camera app for permission to use the camera (and, I suspect, changing this behaviour will cause partners to push back).
c. see notes above re: comment 60.