975453 - [B2G][Camera]Unable to stop recording video when quickly switching to camera mode after pressing record

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Camera, defect)

Description

[Andrew Stole [:astole]]

After pressing record and then quickly pressing the camera icon, the user is unable to switch back to video mode to stop the recording. The user is also able to take pictures while the video is recording.

Repro Steps:
1) Updated Buri to BuildID: 20140221040202
2) Open camera app and switch to video mode
3) Press record
4) Immediately after pressing record, press the camera icon to return to camera mode

Actual:
User is able to switch to camera mode after starting a recording.

Expected:
The user is unable to switch to camera mode after pressing record.

Environmental Variables:
Device: Buri v1.4 M/C Mozilla RIL
BuildID: 20140221040202
Gaia: 35365feace970bfc51276428f40a477c9c86b7bb
Gecko: 7010ab83a06e
Version: 30.0a1
Firmware Version: V1.2-device.cfg

Repro frequency: 100%
See attached: Video

Comment 1

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

Diego, do we disable the mode-switch button before starting recording?

On the plus side, this proves picture-taking-while-recording. :)

Comment 2

[Jason Smith [:jsmith]]

Can we verify this doesn't reproduce on 1.3?

Comment 3

[Chris Kreinbring [:CKreinbring]]

Unable to repro on Buri 1.3 mozilla RIL.  The Camera button is disabled once video recording has started.

Build ID: 20140221004002
Gecko: https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/e5f25becc0e7
Gaia: 8039a5cb7519adfa81677df577f494c6a4de6140
Platform Version: 28.0
Firmware Version: V1.2-device.cfg

Comment 4

[John Hammink]

I am able to reproduce this on 1.3 also:

Gaia      8039a5cb7519adfa81677df577f494c6a4de6140
Gecko     https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/e5f25becc0e7
BuildID   20140221004002
Version   28.0
ro.build.version.incremental=324
ro.build.date=Thu Dec 19 14:04:55 CST 2013

Comment 5

[Jason Smith [:jsmith]]

One thing I'd like to know here is specifically if the camera is still recording when this happens. You can figure this out by going to the homescreen after the STR is complete & checking if a red dot is present.

Comment 6

[John Hammink]

...albeit not as consistently on 1.3.  Grrrr.

On 1.4 after restarting the phone, I am actually seeing the desired result again and thus cannot repro.   If anyone can repro, and check comment 5, that'd be helpful.

Comment 7

[pfield]

(In reply to Jason Smith [:jsmith] from comment #5)
> One thing I'd like to know here is specifically if the camera is still
> recording when this happens. You can figure this out by going to the
> homescreen after the STR is complete & checking if a red dot is present.

Tested and the phone does indeed keep recording while this issue is occuring.

Comment 8

[Jason Smith [:jsmith]]

Okay - while the STR has a low probability, the privacy issue is concerning - we're recording outside of the user's control. It's a regression as well - I talked w/John in person & I don't think the bug he found on 1.3 is the same as this issue.

Comment 9

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #8)
> Okay - while the STR has a low probability, the privacy issue is concerning
> - we're recording outside of the user's control. It's a regression as well -
> I talked w/John in person & I don't think the bug he found on 1.3 is the
> same as this issue.

Although note - a user could technically kill the camera app to kill the recording. Then again, watching the video, it's technically possible someone could decide to start a recording & then decide against it. There's also the probability that this could get caught in QC CS testing, as QC's testing process often tests workflows in the camera app involving switching modes, including at higher speeds.

Personally I'd rather be defensive and block & fix this, then risk finding out later when QC finds the bug and claims it's a CS blocker.

Comment 10

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #9)
> (In reply to Jason Smith [:jsmith] from comment #8)
> > Okay - while the STR has a low probability, the privacy issue is concerning
> > - we're recording outside of the user's control. It's a regression as well -
> > I talked w/John in person & I don't think the bug he found on 1.3 is the
> > same as this issue.
> 
> Although note - a user could technically kill the camera app to kill the
> recording. Then again, watching the video, it's technically possible someone
> could decide to start a recording & then decide against it. There's also the
> probability that this could get caught in QC CS testing, as QC's testing
> process often tests workflows in the camera app involving switching modes,
> including at higher speeds.
> 
> Personally I'd rather be defensive and block & fix this, then risk finding
> out later when QC finds the bug and claims it's a CS blocker.

Okay - I checked historically - we have blocked on cases where functionality in the camera became non-functional from random touch interactions. See bug 890427 as an example. Monkey testing would probably find a bug like this.

Comment 11

[Hema Koka [:hema]]

Justin, please take a look at this?

Also NI Diego for comment #1 

Thanks
Hema

Comment 12

[David Flanagan [:djf]]

Does the camera really keep recording, or does the red dot just remain in the status bar?  (I.e. what do you see in the recorded video?)

I used to see the red dot not going away a lot, and always assumed it was a system app bug in the status bar.  The camera app doesn't do anything to make that red dot appear or disappear.

Comment 13

[Diego Marcos [:dmarcos]]

The switch button was not disabled when triggering recording. The attached PR addresses the original issue.

The camera doesn't keep recording after exiting the app but the red dot is displayed on the status bar when returning to the home screen. This is a different issue and probably a system app bug as djf mentioned.

Is not a bug already keeping track of that issue?

Comment 14

[Diego Marcos [:dmarcos]]

Attachment: Pull Request

Comment 15

[Diego Marcos [:dmarcos]]

https://github.com/mozilla-b2g/gaia/commit/a2d48c1a41f78bb7896df32359a19011b713ac5f

Comment 16

[David Flanagan [:djf]]

Diego: you didn't close the bug after landing your patch. But that is just as well because I was about to re-open it.

Your patch doesn't handle the case where recording can't stop (because of not enough storage space, for example.) In that case the buttons get disabled, and are then never re-enabled.   I think you need to emit 'ready' from onRecordingError(). 

It is probably worth backing out this commit, adding this fix and relanding a single patch.

Jason: we think that the persistant red dot is not actually a privacy issue in camera but a bug in whatever code displays the red dot.  Do you know if there is already a bug filed for that?

Comment 17

[Jason Smith [:jsmith]]

(In reply to David Flanagan [:djf] from comment #16)
> 
> Jason: we think that the persistant red dot is not actually a privacy issue
> in camera but a bug in whatever code displays the red dot.  Do you know if
> there is already a bug filed for that?

A persistent red dot actually is a privacy issue - you are indicating that you are recording something when in reality, you are not. This leads the user to believe to be confused on trying to figure out what's actually being recorded, even though there isn't anything being recorded. Without a sense of control, the user begins to think that the phone is recording something for an unknown use case, which will trouble a user into thinking possible thoughts of what the recording is being used for.

I don't know of a bug on file for this though. We should file a bug for this.

Comment 18

[Diego Marcos [:dmarcos]]

Closing this bug. Created follow up Bug 977422 to renable controls when recording fails. PR already attached to it.

Bug 977427 keeps track of the problem of the red dot not going away.