Closed Bug 1080912 Opened 6 years ago Closed 5 years ago

[Camera]The camera button and video button will fail to function when the user opens and closes the camera app multiple times via the home button

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:2.1+, b2g-v2.0 unaffected, b2g-v2.1 verified, b2g-v2.2 fixed)

VERIFIED FIXED
2.1 S8 (7Nov)
blocking-b2g 2.1+
Tracking Status
b2g-v2.0 --- unaffected
b2g-v2.1 --- verified
b2g-v2.2 --- fixed

People

(Reporter: cnelson, Assigned: dmarcos)

References

()

Details

(Keywords: regression, Whiteboard: [2.1-flame-test-run-3])

Attachments

(4 files)

Attached file logcatCamera.txt
When the user opens and closes the camera app multiple times via the home button, the picture and video buttons will fail to function.  Note that the user must open and close the camera app quickly in order to reproduce this issue.
   
Repro Steps:
1) Update a Flame device to BuildID: 20141008000201
2) Open the camera app and quickly close it via the home button mutliple times.
3) Open the camera app for the third or fourth time.
4) Press the picture and or the video button.
5) Notice the picture and video buttons will fail to function.
  
Actual:
The picture and video buttons will fail to function when the user quickly opens and closes the camera app via the home button.
  
Expected: 
The picture and video buttons always function.
  
Environmental Variables:
Device: Flame 2.1
BuildID: 20141008000201
Gaia: d71f8804d7229f4b354259d5d8543c25b4796064
Gecko: 7fa82c9acdf2
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
  
  
Repro frequency: 80%
See attached: logcat, video https://www.youtube.com/watch?v=WXmb7Vn1ngY
Flags: needinfo?(dharris)
This issue does occur on Flame 2.2 Master KK (319mb) (Full Flash)

The picture and video buttons will fail to function when the user quickly opens and closes the camera app via the home button.

Flame 2.2 Master KK (319mb) (Full Flash)

Environmental Variables:
Device: Flame 2.2 Master
BuildID: 20141008065430
Gaia: 0bc74ce502672cf0265b24cf3a25d117c3de5e71
Gecko: dd7637cc42d5
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

This issue doesn't occur on Flame 2.0 KK (319mb) (Full Flash)

Flame 2.0 KK (319mb) (Full Flash)

Environmental Variables:
Device: Flame 2.0
BuildID: 20141008000202
Gaia: 31a49c7932c7085961760a6bef9ed381ea38d7e3
Gecko: a2d707e79061
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 32.0 (2.0)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
[Blocking Requested - why for this release]:

This is a regression, and the user can be completely blocked from taking a picture in the camera app. Nominating this to block 2.1
blocking-b2g: --- → 2.1?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(dharris)
Flags: needinfo?(dmarcos)
Blocking Reason: agree with comment 2
Assignee: nobody → dmarcos
blocking-b2g: 2.1? → 2.1+
QA Contact: aalldredge
Regression Window unavailable because issue occurs in earliest KK build we have and does not repro in JB base.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
QA Contact: aalldredge
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
I tried this with following build and V184 base (close to 10 or 12 times rapidly) and I am unable to reproduce the case where camera buttons fail to function. 

Gaia-Rev        379ea4c9dd6d3f8ca2f79ce59c15f6afe6e557c3
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/4853208cb48a
Build-ID        20141015001201
Version         34.0
Device-Name     flame-kk
FW-Release      4.4.2
FW-Incremental  34

No-Jun,

could you please try as well?
Flags: needinfo?(npark)
This is consistently reproducible in 2.1.
once the Camera app is tapped, repeatedly tap the home button until the camera app is closed.  No need to wait for the camera app response.

Version Info:
Gaia-Rev        477a9e61c3edf12f32a62a19d329cd277202cc6b
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/67573e422a0f
Build-ID        20141016001201
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141016.034320
FW-Date         Thu Oct 16 03:43:30 EDT 2014
Bootloader      L1TC00011840
Flags: needinfo?(npark)
I cannot reproduce this in latest master on full memory configuration:

Gaia-Rev        dc496d04907dd314f9736ff78bab3bd27156f79a
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/ca6b46cbca3b
Build-ID        20141020040204
Version         36.0a1
Device-Name     flame
FW-Release      4.4.2

No-Jun, Can you still reproduce?
Flags: needinfo?(dmarcos) → needinfo?(npark)
(In reply to Diego Marcos [:dmarcos] from comment #7)
> I cannot reproduce this in latest master on full memory configuration:
> 
> Gaia-Rev        dc496d04907dd314f9736ff78bab3bd27156f79a
> Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/ca6b46cbca3b
> Build-ID        20141020040204
> Version         36.0a1
> Device-Name     flame
> FW-Release      4.4.2
> 
> No-Jun, Can you still reproduce?

I have the same gecko/gaia in 319MB configuration, and I can reproduce this consistently.  I just tried with 512MB setting, and I can still reproduce it.  When I tap the switch, I get focus circle instead of the switch flick.  Took a video of it below:

https://www.dropbox.com/s/jog323g4tsfvl90/mode%20switch%20frozen.mp4?dl=0
Flags: needinfo?(npark)
What OEM build are you running on? Can you reproduce on full memory configuration (1GB)? 

Does this reproduce on a production device? Not Flame with capped memory.
Flags: needinfo?(npark)
I have tested it on v184 and v188 base image, and I can also repro this on 1GB memory configuration.  Only production device I have is hamachi, and I can repro it there as well. I don't have any current production devices though, perhaps Mike can check whether this happens on his Open C device?
Flags: needinfo?(npark) → needinfo?(mhabicher)
Just tested it in Open C device with the latest master image, and I can reproduce the bug here as well.
Flags: needinfo?(mhabicher)
I narrowed down the cause. We still don't properly protect the switch button against button bashing. You can get the controls permanently disabled by tapping quickly on the switch for a little while. Wilson might have a good guess of what's going on here. bug 1061996 seemed to fix the issue but the following line added by bug 1066660 looks like introduces new problems:

https://github.com/mozilla-b2g/gaia/blob/master/apps/camera/js/controllers/controls.js#L248

No-Jun, can you try the following PR and see if you can still reproduce the issue? 

https://github.com/mozilla-b2g/gaia/pull/25388
Flags: needinfo?(wilsonpage)
Flags: needinfo?(npark)
(In reply to Diego Marcos [:dmarcos] from comment #12)
> bug 1061996 seemed to fix the issue but the
> following line added by bug 1066660 looks like introduces new problems:
> 
> https://github.com/mozilla-b2g/gaia/blob/master/apps/camera/js/controllers/
> controls.js#L248

Woah, I have no idea how that line got re-introduced! I removed that line as part of bug 1061996. It's super important that we only allow controls to be disable and enabled via the 'ready', 'busy' callbacks. This is because in some cases mode selection doesn't go ahead and the controls remain disabled as no 'ready' event ever fires.

Apologies, the only was I can think this could have happened is some code merge weirdness :(
Flags: needinfo?(wilsonpage)
Attached file Pull Request
It removes the following line:

https://github.com/mozilla-b2g/gaia/blob/master/apps/camera/js/controllers/controls.js#L248

It was removed and reintroduced by bug 1066660 by mistake:

https://github.com/mozilla-b2g/gaia/pull/24010/files#diff-f234e3b8bf8b3f22b401a1ac46ce6652R248

No-Jun, Can you please verify if the PR fixes the issue? Thank you!
Attachment #8509505 - Flags: review?(wilsonpage)
(In reply to Diego Marcos [:dmarcos] from comment #14)
> Created attachment 8509505 [details] [review]
> Pull Request
> 
> It removes the following line:
> 
> https://github.com/mozilla-b2g/gaia/blob/master/apps/camera/js/controllers/
> controls.js#L248
> 
> It was removed and reintroduced by bug 1066660 by mistake:
> 
> https://github.com/mozilla-b2g/gaia/pull/24010/files#diff-
> f234e3b8bf8b3f22b401a1ac46ce6652R248
> 
> No-Jun, Can you please verify if the PR fixes the issue? Thank you!

I noticed this patch is already applied in 2.1 branch, but on master this line was undeleted for some reason.  
In 2.1, the mode switch is correctly working, but I noticed another problem in both 2.1 and master.  After trying the STR a few times, I get a dark viewfinder with spinning wheels indefinitely when I resume the camera app.  I'm on v188 base image.  I'll attach the logcat below in case it helps.
Flags: needinfo?(npark)
Attached file camera.log
Logcat while tapping the camera app and bashing homescreen repeatedly, and repeating this process a few times until I see a permanent spinning wheel on viewfinder.
(In reply to No-Jun Park [:njpark] from comment #16)
> Created attachment 8509520 [details]
> camera.log
> 
> Logcat while tapping the camera app and bashing homescreen repeatedly, and
> repeating this process a few times until I see a permanent spinning wheel on
> viewfinder.

No Jun, we need to make a decision on this bug. Is the problem with the disabled controls gone with this patch? The permanent spinning wheel seems a separate problem. Can you file a new bug?
Flags: needinfo?(npark)
Comment on attachment 8509505 [details] [review]
Pull Request

Code looks good. This is a conditional r+:

- Needs a unit-test to stop this regressing again
Attachment #8509505 - Flags: review?(wilsonpage) → review+
(In reply to Diego Marcos [:dmarcos] from comment #17)
> (In reply to No-Jun Park [:njpark] from comment #16)
> > Created attachment 8509520 [details]
> > camera.log
> > 
> > Logcat while tapping the camera app and bashing homescreen repeatedly, and
> > repeating this process a few times until I see a permanent spinning wheel on
> > viewfinder.
> 
> No Jun, we need to make a decision on this bug. Is the problem with the
> disabled controls gone with this patch? The permanent spinning wheel seems a
> separate problem. Can you file a new bug?

Sure, will file a new bug.  although same STR causes the issue, it now causes the separate issue.
Flags: needinfo?(npark)
Can you reproduce the new issue on v184? I can't
Flags: needinfo?(npark)
Blocks: 1087475
(In reply to Diego Marcos [:dmarcos] from comment #20)
> Can you reproduce the new issue on v184? I can't

You're right, this seems like v188 issue.  I can't repro this in v184 either.  I'll mention this in the new bug
Flags: needinfo?(npark)
Do we know of any changes on the driver side?
Flags: needinfo?(mhabicher)
Flags: needinfo?(aosmond)
Flags: needinfo?(mhabicher)
See Also: → 1087475
Not that I'm away of, though it sounds like there are new issues.

Tony, do we get a changelist or known-issue list of any kind with the new t2m drops?
Flags: needinfo?(tchung)
Mike. You can find release notes here:

https://intranet.mozilla.org/QA/B2G_Tips_and_Tricks#latest_OEM_KitKat_Base_Image_:_v188
Flags: needinfo?(mhabicher)
(In reply to Diego Marcos [:dmarcos] from comment #24)
> Mike. You can find release notes here:
> 
> https://intranet.mozilla.org/QA/
> B2G_Tips_and_Tricks#latest_OEM_KitKat_Base_Image_:_v188

what diego said.  sorry its not very helpful, but its word for word from t2m.
Flags: needinfo?(tchung)
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Comment on attachment 8509505 [details] [review]
Pull Request

[User impact] if declined:

The camera controls might get permanently disabled when closing and opening the camera multiple times in rapid succession.
Attachment #8509505 - Flags: approval-gaia-v2.1?(fabrice)
(In reply to Diego Marcos [:dmarcos] from comment #27)
> Comment on attachment 8509505 [details] [review]
> Pull Request
> 
> [User impact] if declined:
> 
> The camera controls might get permanently disabled when closing and opening
> the camera multiple times in rapid succession.

Where are the other questions of the approval questionnaire?
Flags: needinfo?(dmarcos)
Attachment #8509505 - Flags: approval-gaia-v2.1?(fabrice)
Comment on attachment 8509505 [details] [review]
Pull Request

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): bug 1066660
[User impact] if declined: The camera controls might be permanently disabled
[Testing completed]: Unit tests to cover the regression from bug 1066660
[Risk to taking this patch] (and alternatives if risky): None. 1 line change
[String changes made]: None
Flags: needinfo?(dmarcos)
Attachment #8509505 - Flags: approval-gaia-v2.1?(fabrice)
Attachment #8509505 - Flags: approval-gaia-v2.1?(fabrice) → approval-gaia-v2.1+
Flags: needinfo?(mhabicher)
Flags: needinfo?(aosmond)
The issue still reproduces on 2.2 and 2.1, 
Open and close the camera app a few times with "Home" button, the camera and video is nonfunctional 

Device: Flame 2.2 Master KK
BuildID: 20141030040201
Gaia: 0dfc1996eb583c8b507a82bf6b8319624bba23ea
Gecko: 80e18ff7c7b2
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 36.0a1 (2.2 Master)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Device: Flame 2.1 KK
BuildID: 20141030001201
Gaia: 3e585d8be5e2dffc376f83313299c9b6d53c3db4
Gecko: b643d78a23c6
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 34.0 (2.1)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?][failed-verification]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?][failed-verification] → [QAnalyst-Triage+][failed-verification]
Flags: needinfo?(ktucker)
What do you mean by camera and video not being functional?

This bug only covers when the controls remain disable after closing and opening the camera in quick succession. 

There's a separate bug to address the case where the preview is not available: bug 1087475. It has landed on master on a later commit that the one you're testing.
Flags: needinfo?(sarsenyev)
If you refer to the YouTube video link URL https://www.youtube.com/watch?v=WXmb7Vn1ngY, that is provided above, you will see it's exactly the same issue it not about "Disabled" buttons, it's about the "Focus" icon is blocking from tapping "Camera" and "Video" icons, the bug that you refer to is a dupe of this bug.
Flags: needinfo?(sarsenyev)
N(In reply to sarsenyev from comment #33)
> If you refer to the YouTube video link URL
> https://www.youtube.com/watch?v=WXmb7Vn1ngY, that is provided above, you
> will see it's exactly the same issue it not about "Disabled" buttons, it's
> about the "Focus" icon is blocking from tapping "Camera" and "Video" icons,
> the bug that you refer to is a dupe of this bug.

bug 1087475 is not a duplicate. It *DEPENDS* on this bug. It covers when the preview is not available (black preview). This bug covers when the controls are disabled. It manifests on the events going through the controls hitting the preview and triggering a focus cycle that displays the focus ring (what you see in the video)

What are you exactly seeing? The problem in the video you linked or something different? Can you be specific? 

https://www.youtube.com/watch?v=WXmb7Vn1ngY
Flags: needinfo?(sarsenyev)
 I have the same issue as is shown on the video. Picture/Video icons are nonfunctional, cannot switch between camera/video and cannot take a picture/video

The issue is that "Viewfinder" is focusing everywhere even on "Camera/Video" icons
The screen doesn't feel different whether the user is  trying to make a picture/video or focusing
Flags: needinfo?(sarsenyev)
This does not reproduce on latest master on my Flame with v188:

Gaia-Rev        74614068b0e98214e96ba7c9877f7c80668785c4
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/80e18ff7c7b2
Build-ID        20141030040201
Version         36.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  40
FW-Date         Tue Oct 21 15:59:42 CST 2014
Bootloader      L1TC10011880

No Jun, Can you confirm this? Thanks!
Flags: needinfo?(npark)
Hmm, I'm seeing this as well as a different problem.  
Right after starting up the phone, when I open and close camera app repeatedly, I see Bug 1087475 again.  It shows dark viewfinder with no spinning wheels, or dark viewfinder with spinning wheels.

Then I kill the app, and without restarting the phone, I repeat the open and close.  Then I see the original bug, where tapping the camera button only causes the tap to focus being activated.  (As you see from the video in Comment 33)  This was originally what I saw when I tested this bug.  

It's strange, because when I applied the patch to the latest gaia, things worked fine with same steps.

Version Info:
Gaia-Rev        8ae6598f3ab7b0c34ac42a73083ddb74266affba
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/e0b505a37b1c
Build-ID        20141031040201
Version         36.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141031.072452
FW-Date         Fri Oct 31 07:25:03 EDT 2014
Bootloader      L1TC00011880
Status: RESOLVED → REOPENED
Flags: needinfo?(npark)
Resolution: FIXED → ---
Depends on: 1085759
It seems that full flashing from PVT is installing bogus builds that make fixed bugs come back from the dead (It's appropriate on Halloween night). I manually updated my flame to v188 and installed latest gaia/gecko on top and I cannot reproduce the original problem. Let's wait for bug 1085759 to be resolved and retest.
(In reply to Diego Marcos [:dmarcos] from comment #38)
> It seems that full flashing from PVT is installing bogus builds that make
> fixed bugs come back from the dead (It's appropriate on Halloween night). I
> manually updated my flame to v188 and installed latest gaia/gecko on top and
> I cannot reproduce the original problem. Let's wait for bug 1085759 to be
> resolved and retest.

I also shallow flashed master on top of 2.2 gecko+gaia, and could not reproduce the issue.  Waiting until Bug 1085759 is fixed to re-verify
Target Milestone: 2.1 S7 (24Oct) → 2.1 S8 (7Nov)
We're waiting for the dependencies to be resolved before uplifting this patch.
This bug just need verification after Bug 1085759 is resolved
No-Jun,

Please talk to Tony about how we can still verify this without 1085759 (he figured out a workaround)

Thanks
Hema
Flags: needinfo?(npark)
Status: REOPENED → RESOLVED
Closed: 6 years ago5 years ago
Resolution: --- → FIXED
(In reply to Hema Koka [:hema] from comment #42)
> No-Jun,
> 
> Please talk to Tony about how we can still verify this without 1085759 (he
> figured out a workaround)
> 
> Thanks
> Hema

Hi Hema, I used the workaround to verify this bug
- Locally build 2.1 flame-kk with v188-1 contents into backup-flame folder
- flash the local build
- replace the boot.img on device with the command  fastboot flash boot boot.img
- restart the phone, and test it

This bug is no longer reproducible in 2.1, marking it as verified
Status: RESOLVED → VERIFIED
Flags: needinfo?(npark)
And since it is already in 2.1 build, no further action is needed.
Attached video VIDEO0040_Compress.MP4
This issue has been successfully verified on flame 2.1 build:
Gaia-Rev        1b231b87aad384842dfc79614b2a9ca68a4b4ff3
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/95fbd7635152
Build-ID        20141118001204
Version         34.0
Depends on: 1117859
You need to log in before you can comment on or make changes to this bug.