993686 - [B2G][Camera] - Tapping repeatedly on capture button while setting wallpaper can permanently freeze the camera app

Status: RESOLVED FIXED

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

Description

[Tony Nguyen]

Attachment: logcat

Description:
After setting a photo as device wallpaper on the homescreen, the user can cause Camera to become unresponsive by continuously tapping on the capture button before Camera completely loads.

Repro Steps:
1) Update Buri to BuildID: 20140408000202
2) Tap and hold on homescreen > Change Wallpaper > Camera
3) While Camera is loading - Continuously tap on the capture button 
4) Tap on Select once the images have been captured
5) Navigate to the Camera App
6) While Camera is loading - Continuously tap on the capture button

Actual:
Camera displays blackscreen and is unresponsive

Expected:
Camera app doesn't become unresponsive

Environmental Variables:
Device: Buri v1.4 mozRIL 
BuildID: 20140408000202
Gaia: 26983f356ecb1bcf30e862d334b5de790071803e
Gecko: 70b076fc7558
Version: 30.0a2
Firmware Version: v1.2-device.cfg

Keywords:  tapping, repeatedly, in, other, than, camera, apps, load, black, screen

Notes:
The Camera app remains unresponsive after killing the Camera App from the Task Manager view and reloading. This is true for when attempting to relaunch the Camera app from any location - Gallery, Video, etc. 

Repro frequency: 4/6 - 66%
See attached: logcat
URL: http://youtu.be/A-lHhIDLFjU

Comment 1

[Tony Nguyen]

This issue does not reproduce on the latest Buri v1.3 mozRIL BuildID: 20140408004002.

Gaia: 0a7a50129995f080c1df4d807a2334701701e8ed
Gecko: e3fca8c23e1d
Version: 28.0
Firmware Version: v1.2-device.cfg

This issue does reproduce on the 03/26 Buri v1.4 mozRIL BuildID:  20140326000201.

Gaia: 7e705dd4718d528974d99ac31866318d7e201152
Gecko: 4889124accfa
Version: 30.0a2
Firmware Version: v1.2-device.cfg

Comment 2

[Jason Smith [:jsmith]]

Can we try to find a STR that's more realistic that an end-user could trigger?

Comment 3

[Rachel Pribble [:rpribble]]

I am unsure what is meant by 'realistic' here. I am achieving this bug with closer to 80-90% repro rate. It seems that the camera button does not need to be spammed. When replacing the wallpaper with the camera app, the UI 'retake' and 'select' buttons are slow to pop up after taking a photo. As long as the user takes two consecutive photos before the retake and select buttons have appeared, the issue occurs. Opening other apps before opening the camera app for the second time (as in StR #5) has no effect on the issue. 

Environmental Variables:
Device: Buri v1.4 MOZ ril
BuildID: 20140411000202
Gaia: 6c50349f41d40ba175ea0fc0c2c2cbd739ba7170
Gecko: 28b419f0e857
Version: 30.0a2
Firmware Version: v1.2-device.cfg

The camera loads in with a black unresponsive screen.

Comment 4

[Jason Smith [:jsmith]]

Using comment 3, can you provide example STR that doesn't involve spamming with a high repro rate?

Comment 5

[Justin D'Arcangelo [:justindarc]]

I actually just noticed that on nexus4, when rapidly tapping the "Capture" button during a pick activity (such as this wallpaper picker here), it is possible to trigger the camera to take a 2nd picture while the "Retake/Select" screen is visible (the camera is focusing for ~1sec. behind the preview screen before you can hear the "snap" sound from taking a picture for the second time and the preview screen then shows the 2nd picture). I'm seeing a 100% repro rate for that on nexus4 (requiring you to rapidly tap the "Capture" button in a pick activity). However, I'm not seeing any black screen issues. I can try this on Hamachi to check and see.

I am curious though to know if this is related to the Camera "pick" activity in general and not specific to the Wallpaper selection. I have a JS Bin set up here with several input[type="file"] pickers for testing activities: http://jsbin.com/xosew

Comment 6

[Rachel Pribble [:rpribble]]

Attachment: UpdatedVideo.ogg

I have attached a video (UpdatedVideo.ogg) of the steps I'm following to get a 100% repro rate on this bug.

Repro Steps:
1) Update Buri to BuildID: 20140411000202
2) Tap and hold on homescreen > Change Wallpaper > Camera
3) When camera has loaded,tap the capture button twice to take two pictures before the 'retake' and 'select' buttons appear
4) Tap on Select once the images have been captured
5) Navigate to the Camera App (opening other apps or performing other tasks before step 6 has no effect, results are the same)
6) Before camera has loaded, tap capture twice with the same timing as in step 3
7) Observe black screen on camera app. Device must be restarted to clear it.

Environmental Variables:
Device: Buri v1.4 MOZ ril
BuildID: 20140415000202
Gaia: c8f916c8569f6ee652237fd10ac925e08cd3d9bc
Gecko: f14047fa8d63
Version: 30.0a2
Firmware Version: v1.2-device.cfg

Repro rate: 100%

Comment 7

[Jason Smith [:jsmith]]

Okay - the video makes this look a bit more realistic to hit. The fact that we require a device restart to workaround this seems quite bad.

Comment 8

[Marcia Knous [:marcia]]

Adding master as affected since it is pretty easy to reproduce that there. I wasn't able to reproduce it on Nexus 4 - have a feeling that has something to do with the fact that the phone is faster to respond than the Buri.

Comment 9

[Dave Hylands [:dhylands]]

Since its fairly easy to reproduce, and camera is getting a lot of emphasis, we've decided to block on this.

Comment 10

[Pi Wei Cheng [:piwei] (inactive)]

b2g-inbound Regression Window:

Last Working Environmental Variables:
Device: Buri MOZ
BuildID: 20140317095627
Gaia: 3ad16c6017b78f6f7d0008f75ac16af011fcb14c
Gecko: ca88f9016809
Version: 30.0a1
Firmware Version: v1.2-device.cfg

First Broken Environmental Variables:
Device: Buri MOZ
BuildID: 20140317101128
Gaia: 99890f3d9309ed5c696e110533aea5b6281f65d6
Gecko: a0618b266f28
Version: 30.0a1
Firmware Version: v1.2-device.cfg

Last Working Gaia / First Broken Gecko: Issue Does NOT reproduce
Gaia: 3ad16c6017b78f6f7d0008f75ac16af011fcb14c
Gecko: a0618b266f28

Last Working Gecko / First Broken Gaia: Issue DOES reproduce
Gaia: 99890f3d9309ed5c696e110533aea5b6281f65d6
Gecko: ca88f9016809

Gaia Pushlog:
https://github.com/mozilla-b2g/gaia/compare/3ad16c6017b78f6f7d0008f75ac16af011fcb14c...99890f3d9309ed5c696e110533aea5b6281f65d6

Note:
I noticed that with the old camera UI, this issue is harder to reproduce; the original reporter's repro steps need to be strictly executed, and even with that it's not 100% reproducible (as stated originally). I had to try at least 4 times to make sure the build does not exhibit the problem. With the new camera UI this issue is easier to reproduce.

Comment 11

[Jason Smith [:jsmith]]

Can we find out if this reproduces on Tarako?

Comment 12

[Jason Smith [:jsmith]]

Caused by bug 949941.

Comment 13

[Pi Wei Cheng [:piwei] (inactive)]

Issue is not reproducible on Tarako. Issue occurred 0 out of 7 attempts.

Device: Tarako 1.3T MOZ
BuildID: 20140417004002
Gaia: a8d2d399f2939f4845abaa0df57abab241a2c782
Gecko: d97dad54cb61
Version: 28.1
Firmware Version: sp6821

Comment 14

[Justin D'Arcangelo [:justindarc]]

This is 100% reproducible on Hamachi running latest build from master. However, the STR is slightly simpler as it is not necessary to repeatedly attempt to press the shutter button when launching Camera for the 2nd time (Step 6 from original STR).

Comment 15

[Justin D'Arcangelo [:justindarc]]

Attachment: pull-request (master)

Comment 16

[Justin D'Arcangelo [:justindarc]]

This patch should resolve the issue. It looks like the rapid pressing of the capture button was causing the app to get backed up with processing the preview images and the confirmation callback was getting called too late. Then, in the confirmation callback, it was incorrectly restarting the camera preview stream after it should have already been closed which caused the camera hardware to never get released. The subsequent Camera app launches would then fail (until reboot) because the camera hardware wasn't properly released in the pick activity.

Comment 17

[David Flanagan [:djf]]

Comment on attachment 8409143 [details] [review]
pull-request (master)

Giving r- here because it looks like this patch will break the "retake" button.  Should be trivial to fix that, though.

Also, needinfo on mike to ask why the camera hardware doesn't get released automatically when the pick activity exits and that instance of the camera app dies.  I agree that we should land Justin's patch to prevent this symptom, but it seems to me that there is a deeper bug here if the camera hardware can get tied up like this even when the process exits.

Comment 18

[Justin D'Arcangelo [:justindarc]]

Comment on attachment 8409143 [details] [review]
pull-request (master)

David: Please re-review. I fixed the issue we discussed where the displaying of the 'confirm' view was being delayed. It is now impossible to repeatedly trigger the 'Capture' button in this updated PR.

Comment 19

[David Flanagan [:djf]]

Comment on attachment 8409143 [details] [review]
pull-request (master)

r- again because now the user can't tap the shutter twice, but they can tap the "Select" button in the confirm dialog before the photo or video is actually ready to be returned in the activity.  So I think you need to disable the button when you show the dialog and then enable it when you display the media.

Comment 20

[Justin D'Arcangelo [:justindarc]]

Comment on attachment 8409143 [details] [review]
pull-request (master)

David: Good catch. Updated the PR to disable the Retake/Select buttons until the media is ready.

Comment 21

[David Flanagan [:djf]]

Comment on attachment 8409143 [details] [review]
pull-request (master)

Looks good to me.

Comment 22

[Justin D'Arcangelo [:justindarc]]

Landed on master:

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

Comment 23

[Ryan VanderMeulen [:RyanVM]]

v1.4: https://github.com/mozilla-b2g/gaia/commit/00279fff6ec4d48ce9c9469cd59d9219bb711f73

Comment 24

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

(In reply to David Flanagan [:djf] from comment #17)
> 
> Also, needinfo on mike to ask why the camera hardware doesn't get released
> automatically when the pick activity exits and that instance of the camera
> app dies.  I agree that we should land Justin's patch to prevent this
> symptom, but it seems to me that there is a deeper bug here if the camera
> hardware can get tied up like this even when the process exits.

The camera hardware will get released by the system when the current process dies.

Absent process death, we originally tried to use the cycle collector to clean up the camera, but found it wasn't deterministic enough, so we added the release() method to allow the camera app to explicitly release the underlying hardware.

This should only be an issue where the same process tries to reopen the camera.