1058016 - [v2.1] Cannot take photo or change camera mode after closing then reopening the app a few times

Status: VERIFIED FIXED

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

Description

[Robert Chira [:RobertC]]

Attachment: logcat.txt

If you close then reopen the camera app, the 2 bottom controls do not work.

This issue can be reproduced with manual testing.

Build info v2.1 flame:
Gaia      e424c85eda87a40c0fa64d6a779c3fa368bf770b
Gecko     https://hg.mozilla.org/mozilla-central/rev/daa84204a11a
BuildID   20140825040204
Version   34.0a1
ro.build.version.incremental=110
ro.build.date=Fri Jun 27 15:57:58 CST 2014
B1TC00011230


STR:
1. open camera app and take a picture
2. close camera app
3. repeat from step 1

Expected result:
It should be possible to take photos each time

Actual result:
After closing and reopening the app a few times (in my case 3 times) the bottom controls stop working. The buttons at the top still work as expected.
I attached the logcat from when I was performing the STR manually.

Comment 1

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

I cannot reproduce this issue running:

- gonk:  v123
- gecko: b2g-inbound:8f2fa20f92a5
- gaia:  master:36f28696046ca9d3bfd4edf38f231dc8fcafbe2f

Comment 2

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

RobertC, can you recording a video if this issue happening and attach it to this bug?

Comment 3

[Jason Smith [:jsmith]]

QA Wanted to see if someone else can reproduce on trunk.

Comment 4

[Cody Roesch [:croesch]]

I WAS able to get this bug to occur on the Flame 2.1 build below. I followed the steps as reported but did it fairly quickly. So as soon as I took the photo, I long pressed home and swiped the camera up to close. I then reopened the camera app, the camera buttons at the bottom no longer respond.

3/3 attempts.
Will attach video in next comment.

Environmental Variables:
Device: Flame Master
BuildID: 20140825085054
Gaia: a25ae14dbd2fe3e25144a7064efc0cc4e31042b8
Gecko: 4ca2bd0722d9
Version: 34.0a1 (Master) 
Firmware Version: v123

Comment 5

[Cody Roesch [:croesch]]

Here is the video link
http://youtu.be/MuNeSvzKxc0

Comment 6

[Joshua Mitchell (Inactive)]

Qa-Wanted for Branch checks now that we have a reliable repro

Comment 7

[Cody Roesch [:croesch]]

This bug repro's on: Flame 2.1

Actual Results: Camera buttons become non functional after taking pictures, closing and reopening camera app.

Repro Rate: 5/5

Environmental Variables:
Device: Flame Master
BuildID: 20140825085054
Gaia: a25ae14dbd2fe3e25144a7064efc0cc4e31042b8
Gecko: 4ca2bd0722d9
Version: 34.0a1 (Master) 
Firmware Version: v123

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

This bug does NOT repro on: Flame 2.0, Flame 1.4, OpenC 2.1

Actual Result: No problems with camera app buttons when closing and reopening.

Repro Rate: 0/10 attempts

Environmental Variables:
Device: Flame 2.0
BuildID: 20140825110552
Gaia: b4d9146623db3bbff9dc36b4a70543e2b0aa497a
Gecko: cef04b609692
Version: 32.0 (2.0) 
Firmware Version: v123
--------------------------------------------------
Environmental Variables:
Device: Flame 1.4
BuildID: 20140825062151
Gaia: cf9d74da6653efeb43d9653e81c61aa00e693a67
Gecko: cdcb73d0febc
Version: 30.0 (1.4) 
Firmware Version: v123
--------------------------------------------------
Environmental Variables:
Device: Open_C Master
BuildID: 20140825085054
Gaia: a25ae14dbd2fe3e25144a7064efc0cc4e31042b8
Gecko: 4ca2bd0722d9
Version: 34.0a1 (Master) 
Firmware Version: P821A10V1.0.0B06_LOG_DL

Comment 8

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

This looks like the UI is missing one or more expected events.

Comment 9

[Joshua Mitchell (Inactive)]

[Blocking Requested - why for this release]: regression in a major feature that can prevent use

Comment 10

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

Justin, I forgot Diego is away this week. Do you have time to take a quick look at this? According to comment 7, it's on Flame/2.1 only.

Comment 11

[Chris Kreinbring [:CKreinbring]]

Regression window
Last working
BuildID: 20140813085958
Gaia: 2864a8d4413746a5359bbcc5042ef776ed06009a
Gecko: 6a7be7376caa
Platform Version: 34.0a1
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

First broken
BuildID: 20140813121354
Gaia: a2219a55145e730e56e09527b40152d68a43b0d9
Gecko: 168401edb50d
Platform Version: 34.0a1
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Working Gaia / Broken Gecko = No repro
Gaia: 2864a8d4413746a5359bbcc5042ef776ed06009a
Gecko: 168401edb50d
Broken Gaia / Working Gecko = Repro
Gaia: a2219a55145e730e56e09527b40152d68a43b0d9
Gecko: 6a7be7376caa
Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/2864a8d4413746a5359bbcc5042ef776ed06009a...a2219a55145e730e56e09527b40152d68a43b0d9


B2G inbound
Last working
BuildID: 20140813065211
Gaia: 70697f90527276a914bb6e2e792938380e2791bb
Gecko: 7e677dfa3c49
Platform Version: 34.0a1
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

First broken
BuildID: 20140813084154
Gaia: 52d2425b8f1e8e3cd7934cc7b75b691c47ad0c02
Gecko: e2b023483c04
Platform Version: 34.0a1
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Working Gaia / Broken Gecko = No repro
Gaia: 70697f90527276a914bb6e2e792938380e2791bb
Gecko: e2b023483c04
Broken Gaia / Working Gecko = Repro
Gaia: 52d2425b8f1e8e3cd7934cc7b75b691c47ad0c02
Gecko: 7e677dfa3c49
Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/70697f90527276a914bb6e2e792938380e2791bb...52d2425b8f1e8e3cd7934cc7b75b691c47ad0c02

Comment 12

[Joshua Mitchell (Inactive)]

possibly broken by bug 1051200 ? Diego, can you take a look?

Comment 13

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

Diego is OoO this week.

Comment 14

[Sri Kasetti]

Making this a blocker since we can reproduce this often

Comment 15

[Andrew Osmond [:aosmond] (he/him)]

(In reply to Joshua Mitchell [:Joshua_M] from comment #12)
> possibly broken by bug 1051200 ? Diego, can you take a look?

It is possible bug 1056347 and bug 1056173 are interacting with this on more recent builds, although they would have come in after the original issue was discovered. The former prevented a UI lockup (very similar to this, except the photo button normally was blue / pressed) somehow by changing event ordering / avoiding interrupts, and the latter fixes the actual interrupted and error cases when they do happen.

Comment 16

[Justin D'Arcangelo [:justindarc]]

This issue is caused by Bug 1058425. Flagging Dave for more info.

Comment 17

[Dave Hylands [:dhylands]]

This sounds like an issue at the media storage level.

It isn't posible for device storage to return files for a non-existent scard. Device Storage doesn't cache any information. It goes to the media and returns the files. No media - no files.

So I have to conclude that the files are coming from the database.

There may also be some confusion in the settings app, since it has some heuristics to figure out how to label the storage areas. On some phones 'sdcard' corresponds to an external physical sdcard (like the buri), and other phones it corresponds to an internal storage area (flame).

Comment 18

[Justin D'Arcangelo [:justindarc]]

While I still believe this is caused by Bug 1058425, the patch I landed in Bug 1060500 should now properly display the "No memory card" overlay when this behavior is exhibited. However, I just noticed that I am unable to reproduce this on KK-based Flame v166. I can still reproduce on JB-based Flame v123 though.

Comment 19

[[e-mail], [e-mail]]

Since bug 943825 landed, settings app will change default media location to be internal storage while the external storage go into "NoMedia" status. But the issue here, settings app is not launched yet. I suspect getDeviceStorages() API is broken after took some picture.

Comment 20

[Justin D'Arcangelo [:justindarc]]

Attachment: logcat with DeviceStorage logging

Comment 21

[Justin D'Arcangelo [:justindarc]]

Attachment: logcat with DeviceStorage logging

Comment 22

[Justin D'Arcangelo [:justindarc]]

Attachment: logcat with DeviceStorage logging

Comment 23

[Dave Hylands [:dhylands]]

I looked at the logs, and I think I may have a fix.

I filed a separate bug 1063877 and ni? you to see if it fixes the issue.

Comment 24

[Justin D'Arcangelo [:justindarc]]

Robert: Can you please re-test this and see if you are still able to reproduce?

The patch for Bug 1063877 has landed which should have fixed this issue.

Comment 25

[Robert Chira [:RobertC]]

Tested this on v2.0, 2.1, 2.2 and was not able to reproduce the issue.
The patch from Bug 1063877 seems to have fixed the problem. Closing the bug.

Comment 26

[Coler]

Verify passed, this issue can't be repro on Woodduck 2.0，Flame2.0, 2.1, 2.2.
Attached: Verify_Woodduck_CameraFunction.mp4
Reproducing rate: 0/20
Build version:
Woodduck2.0:
Gaia-Rev        ee5cf148b4c546beea9bfb799d2a3ee62074957d
Gecko-Rev       73601b71861cbc2f180c4d2653cec3e9fbb39db5
Build-ID        20141114050313
Version         32.0
Flame2.0:
Gaia-Rev        ab83632c92f9fc571b11d8468b6901cc4ed905c0
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/e21bf45e6c44
Build-ID        20141113000201
Version         32.0
Flame2.1:
Gaia-Rev        569a299ca446f714cd98d5881cc058fd6f6e257b
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/d188e92aa5a6
Build-ID        20141113001200
Version         34.0
Flame2.2:
Gaia-Rev        be8b0151d2f9a4c41fc63952128e0b723cd1161d
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/ab137ddd3746
Build-ID        20141113040205
Version         36.0a1

Comment 27

[Coler]

Attachment: Verify_Woodduck_CameraFunction.MP4