1038938 - [B2G] [Camera][273MB Flame] Long-pressing the Home button while self timer is counting down will cause various errors

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

Description

[Chris Kreinbring [:CKreinbring]]

Attachment: Log of putting camera in card view during self-timer

Description:
Various issues occur when the user long taps the Home button while the self-timer is running in the Camera app.

Repro Steps:
1) Update a Flame to 20140715000201
2) Launch the Camera app.
3) Tap the drawer icon, select Self-Timer, then set it to something other than Off.
4) Tap the drawer icon again then tap the camera icon to start the timer.
5) When the timer starts counting down, long-press the Home button.
6) Observe the device as the Camera app is taken into card view.  Move the device around as well.

Actual:
There is usually a small delay in entering the card view.  After a few seconds, beeping can be heard that usually indicates the timer is about to expire, and sometimes a shutter sound plays.  In rare instances, moving the camera around will cause the image in the card to move around.

Expected:
The Camera app enters card view with no errors, there is no countdown beeping, and the image in the Camera card remains static.

Environmental Variables:
Device: Flame 2.0 (273 MB)
Build ID: 20140715000201
Gaia: 2c6c413ed729d465c52d6c2d5d458e2eee79e956
Gecko: d32649a24965
Platform Version: 32.0a2
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Repro frequency: 40%
See attached video clip and logcat logs

Comment 1

[Chris Kreinbring [:CKreinbring]]

Bug repros on Flame 2.1 (273 MB)

Build ID: 20140715040206
Gaia: 46cd188fdda2397d2b8f3303a184dcd52952e2b2
Gecko: e032c429908b
Platform Version: 33.0a1
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Actual result: After a few seconds, beeping can be heard that usually indicates the timer is about to expire, and sometimes a shutter sound plays.  In rare instances, moving the camera around will cause the image in the card to move around.

--------------------------------------------------------------------------------------------------------

The bug does not repro on Flame 2.0 (512 MB), Flame 1.4, Buri 2.1, Buri 2.0 or Buri 1.4

Flame 2.0 (512 MB)
Build ID: 20140715000201
Gaia: 2c6c413ed729d465c52d6c2d5d458e2eee79e956
Gecko: d32649a24965
Platform Version: 32.0a2
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Flame 1.4 (273 MB)
Build ID: 20140715000202
Gaia: b7d36622c7df92c976c37520ccab25199c7ada91
Gecko: de7ecfb00955
Platform Version: 30.0
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Buri 2.1 (273 MB)
Build ID: 20140715040206
Gaia: 46cd188fdda2397d2b8f3303a184dcd52952e2b2
Gecko: e032c429908b
Platform Version: 33.0a1
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Buri 2.0 (273 MB)
Build ID: 20140715000201
Gaia: 2c6c413ed729d465c52d6c2d5d458e2eee79e956
Gecko: d32649a24965
Platform Version: 32.0a2
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Buri 1.4 (273 MB)
Build ID: 20140715000202
Gaia: b7d36622c7df92c976c37520ccab25199c7ada91
Gecko: de7ecfb00955
Platform Version: 30.0
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Actual result: The countdown sound does not play unless the self timer is at the 4 or 5 second mark, and the card view always shows a static image.

Comment 2

[Chris Kreinbring [:CKreinbring]]

Another thing that has been noticed is that tapping the Camera app card will sometimes have no response.  This happens about 70% of the time.

Comment 3

[Mishra]

I checked the issue in following build and the issue is not reproducible

Hardware : Mako
Platform Version : 33.0a1
Build Identifier: 20140715124800

Comment 4

[KTucker [:KTucker][Inactive 3/4/2016]]

This is a regression on the Flame but i feel like this issue is minor and not a blocker.

Comment 5

[KTucker [:KTucker][Inactive 3/4/2016]]

Please disregard Comment 4. After reproducing this issues a few times, the user completely lost the view finder on the camera. Nominating this 2.0? since this is a regression and can lead to more serious issues in camera.

Comment 6

[Hema Koka [:hema]]

David, Please investigate. 

Thanks!

Comment 7

[Diego Marcos [:dmarcos]]

Does this reproduce on QRD?

Comment 8

[Duane Dixon [:ddixon]]

We are not sure what you mean by "QRD".  This bug DOES reproduce on our Flame device with a 2.1 build installed (memory: 273 MB).

Comment 1 has our complete Branch Check.

Comment 9

[Duane Dixon [:ddixon]]

Issue DOES occur on the earliest Flame 2.1 build we have access to. 

Repro rate: about 25%

Environmental Variables:
Device: Flame Master
Build ID: 20140417000006
Gaia: 7591e9dc782ac2e97d63a96f9deb71c7b3588328
Gecko: e71ed4135461
Version: 31.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:31.0) Gecko/31.0 Firefox/31.0

Comment 10

[Joshua Mitchell (Inactive)]

Regression window unavailable - occurs on the oldest build we have access to

Comment 11

[David Flanagan [:djf]]

This is not a camera bug, or at least not a bug that we can do anything about in the camera app.

As best as I can tell, what is going on is that the System, Homescreen and Cameras apps are all running at the same time and are using more memory than the device has, so zmem swapping is required to keep them all alive.

When I try to take a picture, parts of the camera app need to be swapped in, so taking a picture is slow.

When I quick press on the home button, parts of the homescreen need to be swapped in, so returning to the homescreen is slow.

When I long press on the home button, parts of the system app need to be swapped in, so displaying the task switcher is slow (really slow in this case).

The task switcher shrinks the running window down to a small size and keeps it running while it takes a screenshot of it.  Since the camera is displaying a live video feed we can see the image continue to move while the system app processes the screenshot.  Because running a live video feed is memory-intensive, we probably have a situation where memory is thrashing between the camera and the system app.  There are all sorts of bug here even without a countdown timer, but with the timer running it appears that the camera app does not receive the event telling it that it has been hidden for more than 10 seconds. So the countdown timer keeps running and we hear the beeps and even the shutter sound.

In summary:

1) there is not a camera bug here.

2) In the 273mb configuration the camera is barely useable in any case, even ignoring this particular bug. So I'm not sure it makes sense to block on this one.

Alive: could you take a look at this? In particular, note that on a 273mb Flame, it can take more than 10 seconds to bring up the task switcher from the camera app.  The screenshot seems to be generated quickly, but it doesn't display for much longer, and meanwhile the camera viewfinder continues to display a live video feed.  Is there some way you can modify the system app so that it sends the app to the background more quickly? I think this bug would be minimized if the camera knew to stop its video stream sooner.  Or is there some other signal that the camera app could listen for to know when the task manager is being displayed?  If so, then it could stop the preview stream in advance.

Comment 12

[David Flanagan [:djf]]

Alive: in addition to the comment above, I found one more thing to mention to you. While investigating this, I found a few times that I could get into a state where the home button would not work any more. I think what triggered it was long pressing on the home button to bring up the task switcher, and then before the task switcher appeared, I did the same thing again.  Then somehow after that I got back to a working camera app with a broken home button. Do the hardware buttons still work via a state machine? Could we be getting into an unexpected state with multiple long presses and somehow breaking the home button?  I tried to reproduce this and file a bug, but could not reproduce.

Comment 13

[David Flanagan [:djf]]

If this is the wrong component, feel free to reassign. But I don't think there is anything we can do in the camera app to resolve these issues.

Comment 14

[Tim Guan-tin Chien [:timdream] (please needinfo)]

This is the right comp if the above assessment is correct. Unassign David accordingly.

Comment 15

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to David Flanagan [:djf] from comment #12)
> Alive: in addition to the comment above, I found one more thing to mention
> to you. While investigating this, I found a few times that I could get into
> a state where the home button would not work any more. I think what
> triggered it was long pressing on the home button to bring up the task
> switcher, and then before the task switcher appeared, I did the same thing
> again.  Then somehow after that I got back to a working camera app with a
> broken home button. Do the hardware buttons still work via a state machine?
> Could we be getting into an unexpected state with multiple long presses and
> somehow breaking the home button?  I tried to reproduce this and file a bug,
> but could not reproduce.

Hardware button doesn't change for a long time. The hardware key event in browser API is still on going.
If your issue is reproduce-able we could have someone take a look.

I suspect it is related to bug 1037041.

Comment 16

[(inactive after 6/18) Alive Kuo [:alive]]

I cannot reproduce it with master + flame. The camera app goes to background within 1 second when long press home button.
"[Dump: AppWindow][Camera][AppWindow_2][233.726]close with to-cardview" app_window.js:981
"[Dump: AppWindow][Camera][AppWindow_2][233.726]opened,closing,::,close" app_window.js:981
"[Dump: AppWindow][Camera][AppWindow_2][233.728]timer to ensure closed does occur." app_window.js:981
"[Dump: AppWindow][Camera][AppWindow_2][233.730] publishing internal event: closing" app_window.js:981
"[Dump: AppWindow][Camera][AppWindow_2][233.732]handling _closing" app_window.js:981
"[Dump: AppWindow][Camera][AppWindow_2][233.734] publishing external event: closingundefined" app_window.js:981
"[Dump: AppWindow][Camera][AppWindow_2][233.738] publishing internal event: willclose" app_window.js:981
"[Dump: AppWindow][Camera][AppWindow_2][233.741] publishing external event: willcloseundefined" app_window.js:981
"[Dump: AppWindow][Camera][AppWindow_2][233.943]closeAppTowardsCardView has been ENDED!" app_window.js:981
"[Dump: AppWindow][Camera][AppWindow_2][233.944]closing,closed,::,complete" app_window.js:981
"[Dump: AppWindow][Camera][AppWindow_2][233.946] publishing internal event: closed" app_window.js:981
"[Dump: AppWindow][Camera][AppWindow_2][233.947]set visibility -> ,false" app_window.js:981
"[Dump: AppWindow][Camera][AppWindow_2][233.949]screenshot state -> ,screenshot" app_window.js:981
"[Dump: AppWindow][Camera][AppWindow_2][233.950] publishing external event: closedundefined" app_window.js:981
"[Dump: AppWindow][Camera][AppWindow_2][233.951] publishing internal event: close" app_window.js:981
"[Dump: AppWindow][Camera][AppWindow_2][233.951] publishing external event: closeundefined" app_window.js:981
"[Dump: AppWindow][Camera][AppWindow_2][233.968] has been ENDED!" app_window.js:981
"[AppUsage]" "app://camera.gaiamobile.org/manifest.webapp" "ran for" 10 app_usage_metrics.js:92
"[Dump: AppWindow][Camera][AppWindow_2][234.321]getScreenshot succeed!" app_window.js:981
"[Dump: AppWindow][Camera][AppWindow_2][234.322]setVisible on browser element:false" app_window.js:981
"[Dump: AppWindow][Camera][AppWindow_2][234.333] Handling mozbrowservisibilitychange event..." app_window.js:981
"[Dump: AppWindow][Camera][AppWindow_2][234.334] publishing internal event: background" app_window.js:981
"[Dump: AppWindow][Camera][AppWindow_2][234.334] publishing external event: backgroundundefined"


And there's no 2.0 repro-able info in this bug by comment 1. Why is this blocking 2.0 release?

Comment 17

[Jason Smith [:jsmith]]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #16)
> I cannot reproduce it with master + flame. The camera app goes to background
> within 1 second when long press home button.
> "[Dump: AppWindow][Camera][AppWindow_2][233.726]close with to-cardview"
> app_window.js:981
> "[Dump: AppWindow][Camera][AppWindow_2][233.726]opened,closing,::,close"
> app_window.js:981
> "[Dump: AppWindow][Camera][AppWindow_2][233.728]timer to ensure closed does
> occur." app_window.js:981
> "[Dump: AppWindow][Camera][AppWindow_2][233.730] publishing internal event:
> closing" app_window.js:981
> "[Dump: AppWindow][Camera][AppWindow_2][233.732]handling _closing"
> app_window.js:981
> "[Dump: AppWindow][Camera][AppWindow_2][233.734] publishing external event:
> closingundefined" app_window.js:981
> "[Dump: AppWindow][Camera][AppWindow_2][233.738] publishing internal event:
> willclose" app_window.js:981
> "[Dump: AppWindow][Camera][AppWindow_2][233.741] publishing external event:
> willcloseundefined" app_window.js:981
> "[Dump: AppWindow][Camera][AppWindow_2][233.943]closeAppTowardsCardView has
> been ENDED!" app_window.js:981
> "[Dump: AppWindow][Camera][AppWindow_2][233.944]closing,closed,::,complete"
> app_window.js:981
> "[Dump: AppWindow][Camera][AppWindow_2][233.946] publishing internal event:
> closed" app_window.js:981
> "[Dump: AppWindow][Camera][AppWindow_2][233.947]set visibility -> ,false"
> app_window.js:981
> "[Dump: AppWindow][Camera][AppWindow_2][233.949]screenshot state ->
> ,screenshot" app_window.js:981
> "[Dump: AppWindow][Camera][AppWindow_2][233.950] publishing external event:
> closedundefined" app_window.js:981
> "[Dump: AppWindow][Camera][AppWindow_2][233.951] publishing internal event:
> close" app_window.js:981
> "[Dump: AppWindow][Camera][AppWindow_2][233.951] publishing external event:
> closeundefined" app_window.js:981
> "[Dump: AppWindow][Camera][AppWindow_2][233.968] has been ENDED!"
> app_window.js:981
> "[AppUsage]" "app://camera.gaiamobile.org/manifest.webapp" "ran for" 10
> app_usage_metrics.js:92
> "[Dump: AppWindow][Camera][AppWindow_2][234.321]getScreenshot succeed!"
> app_window.js:981
> "[Dump: AppWindow][Camera][AppWindow_2][234.322]setVisible on browser
> element:false" app_window.js:981
> "[Dump: AppWindow][Camera][AppWindow_2][234.333] Handling
> mozbrowservisibilitychange event..." app_window.js:981
> "[Dump: AppWindow][Camera][AppWindow_2][234.334] publishing internal event:
> background" app_window.js:981
> "[Dump: AppWindow][Camera][AppWindow_2][234.334] publishing external event:
> backgroundundefined"
> 
> 
> And there's no 2.0 repro-able info in this bug by comment 1. Why is this
> blocking 2.0 release?

comment 0 indicates this reproduces on 2.0 40% of the time, but only with 273 MB Flame.

Comment 18

[howie [:howie]]

qawanted, see if the problem still exists after several camera 273mb fix.

Comment 19

[Joshua Mitchell (Inactive)]

Qa-wanted:  Check repro in the latest 2.0 and 2.1

Comment 20

[Duane Dixon [:ddixon]]

Issue DOES reproduce on latest Flame 2.0 and 2.1 builds. 
 
(273 MB)
Actual Results: Long pressing home button as Self-Timer hits 5 seconds causes various problems such as: countdown chime continues after app is put in tile view, camera may take photo when in tile mode, user at times cannot re-enter the app once in tile mode, and phone becomes very sluggish and unresponsive. 

2.0 
Device: Flame 2.0
Build ID: 20140721082721
Gaia: b9d19011123487009c80d1200937652d58c434a0
Gecko: d69cd84b6824
Version: 32.0a2 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

2.1 
Device: Flame Master
Build ID: 20140723040045
Gaia: 01d86c8cc615658694b114ca5711763efc4ef205
Gecko: d0f6259e8446
Version: 34.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Comment 21

[Jason Smith [:jsmith]]

QA Wanted - we need to retest this on 319 MB Flame.

Comment 22

[Duane Dixon [:ddixon]]

Issue DOES occur but is less severe and doesn't freeze the phone in 2.0 and 2.1 Flame builds with 319 MB memory.  

Actual Results: Long pressing home button as Self-Timer hits 5 seconds causes the countdown chime to continue after camera app is put in tile view. 

Environmental Variables:
Device: Flame 2.0
Build ID: 20140721082721
Gaia: b9d19011123487009c80d1200937652d58c434a0
Gecko: d69cd84b6824
Version: 32.0a2 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Environmental Variables:
Device: Flame Master
Build ID: 20140724063605
Gaia: c72257b2d27135bfcd68e89dd584182797784016
Gecko: 616e6924cb0b
Version: 34.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Comment 23

[howie [:howie]]

Triage: this is corner case and does not freeze in 319 MB configuration.

Comment 24

[BMO Automation]

Firefox OS is not being worked on