Closed Bug 1007832 Opened 6 years ago Closed 6 years ago

[B2G][1.4][Flame][Camera] App freezes when taking picture after taking video

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:1.4+, firefox30 wontfix, firefox31 wontfix, firefox32 fixed, b2g-v1.3 unaffected, b2g-v1.4 fixed, b2g-v2.0 fixed)

RESOLVED FIXED
2.0 S2 (23may)
blocking-b2g 1.4+
Tracking Status
firefox30 --- wontfix
firefox31 --- wontfix
firefox32 --- fixed
b2g-v1.3 --- unaffected
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed

People

(Reporter: mkruml, Assigned: aosmond)

References

Details

(Keywords: regression, Whiteboard: [flame-1.4-exploratory])

Attachments

(3 files, 1 obsolete file)

Description:
If the user films a video, switches to the camera and attempts to take a picture, the camera app will become unresponsive.

Repro Steps:
1) Update a Flame to BuildID: 20140508000201
2) Navigate to Camera and switch to Video mode
3) Take a seconds-long video, then switch back to camera mode
4) Attempt to take a picture:

Actual:
Button depresses, no picture is taken, and no other buttons function. The user has to press the home button to continue

Expected:
A picture is taken. Functionality remains normal.

1.4 Environmental Variables:
Device: Flame 1.4 MOZ
BuildID: 20140508000201
Gaia: 4ce973ef0732b0d52cb043210db598aa176b2ce9
Gecko: 16ab7f6b18f8
Version: 30.0
Firmware Version: v10E

Does not occur in Open_C 1.4:

1.4 Environmental Variables:
Device: Open_C 1.4 MOZ
BuildID: 20140508000201
Gaia: 4ce973ef0732b0d52cb043210db598aa176b2ce9
Gecko: 16ab7f6b18f8
Version: 30.0
Firmware Version: P821A10-ENG_20140410

Does not occur in Buri 1.4:

1.4 Environmental Variables:
Device: Buri 1.4 MOZ
BuildID: 20140508000201
Gaia: 4ce973ef0732b0d52cb043210db598aa176b2ce9
Gecko: 16ab7f6b18f8
Version: 30.0
Firmware Version: v1.2-device.cfg

Does not occur in Buri 1.3:

1.3 Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140508024005
Gaia: 0d02564946814acfdab13f0b9867d140d318b8ac
Gecko: a7252ab569c4
Version: 28.0
Firmware Version: v1.2-device.cfg

Repro frequency: 100%
See attached: logcat: camers.txt
Attached file camers.txt
Whiteboard: flame-1.4-exploratory → [flame-1.4-exploratory]
Using the more recent Open_C base image, issue does not repro on Open_C 1.4:

1.4 Environmental Variables:
Device: Open_C 1.4 MOZ
BuildID: 20140508000201
Gaia: 4ce973ef0732b0d52cb043210db598aa176b2ce9
Gecko: 16ab7f6b18f8
Version: 30.0
Firmware Version: us_ebay_p821a10v1.0.0b06_LOG_DL
According to the logcat in attachment 8419595 [details], the camera seems to be emitting frames regularly, every 70ms, which is ~14fps. The only error message is "isp_ch_util_hw_notify_sof: meta dump data to bus error" but there's no indication what this means.
Francis - Can you outreach to our partner for Flame about this?
Component: Gaia::Camera → Vendcom
Flags: needinfo?(frlee)
Whiteboard: [flame-1.4-exploratory] → [flame-1.4-exploratory][POVB]
Flame is shipped with v1.3. this is agree in the contract. v1.3 works well and there's no camera app freeze problem. i believe before we request vendor to investigate, we need to make sure it's not FxOS related issue.

although Flame and Open C both use 8210 chipset, but RIL is different. Flame has dsds support. RIL level is definitely different from Open C. it may not be convincible to claim it's vendor's issue since Open C works with our 1.4 gaia/gecko.

QCT won't release 1.4 QCT RIL based on 8210 chipset until E/June. (QCT's current targeted schedule). it will be better to test with 1.4 QCT RIL, or we should test with our own Moz' RIL to ensure RIL level is same for both Open C and Flame.
Component: Vendcom → General
Flags: needinfo?(frlee)
Whiteboard: [flame-1.4-exploratory][POVB] → [flame-1.4-exploratory]
Mike - Can you weigh in here if you agree or disagree that this bug is a vendor issue?
Component: General → Gaia::Camera
Flags: needinfo?(mhabicher)
I don't think (yet) that this is a vendor bug.

Diego, can you take a look at what's going on in the Camera app? If everything looks fine top-side, ni? aosmond and ask him to take a look. He'll be picking up a Flame on Monday.
Flags: needinfo?(mhabicher) → needinfo?(dmarcos)
Can we check to see if this happens on a 1.3 Flame base image?
Keywords: qawanted
This issue reproduce on the 1.3 Flame

1.3 Environmental Variables:
Device: flame 1.3 MOZ
BuildID: 20140414142245
Gaia: 70d6403322ebbbc56b41ef4231e99597a92e3330
Gecko:
Version: 28.0
Firmware Version: v10E
Keywords: qawanted
There we a lot of changes between 1.3 and 1.4 -- that makes me think this is povb.
(In reply to Francis Lee [:frlee] from comment #5)
> Flame is shipped with v1.3. this is agree in the contract. v1.3 works well
> and there's no camera app freeze problem. i believe before we request vendor
> to investigate, we need to make sure it's not FxOS related issue.

This isn't right. comment 9 concludes that this problem reproduces on the Flame 1.3 base image, which makes this a vendor problem.

Francis - Can you send this over to vendor?
Component: Gaia::Camera → Vendcom
Flags: needinfo?(frlee)
Whiteboard: [flame-1.4-exploratory] → [flame-1.4-exploratory][POVB]
I think we should re-test this again with the latest base image v10F-3
I cannot reproduce this with it
Can someone also help to check this issue again?
The build is under https://mozilla.box.com/s/ii8sm72iv5v0955b8f8m
It needs a mozilla account to download it
(In reply to Mike Lien[:mlien] from comment #12)
> I think we should re-test this again with the latest base image v10F-3
> I cannot reproduce this with it
> Can someone also help to check this issue again?
> The build is under https://mozilla.box.com/s/ii8sm72iv5v0955b8f8m
> It needs a mozilla account to download it

We are running the last base image. We're not retesting this again, as the contractor has repeatedly checked & managed to reproduce this on the base image.
(In reply to Jason Smith [:jsmith] from comment #13)
> (In reply to Mike Lien[:mlien] from comment #12)
> > I think we should re-test this again with the latest base image v10F-3
> > I cannot reproduce this with it
> > Can someone also help to check this issue again?
> > The build is under https://mozilla.box.com/s/ii8sm72iv5v0955b8f8m
> > It needs a mozilla account to download it
> 
> We are running the last base image. We're not retesting this again, as the
> contractor has repeatedly checked & managed to reproduce this on the base
> image.

Oh wait - disregard, the bug was filed with 10E. This does need to be retested then with the latest base image.
Flags: needinfo?(frlee)
Flags: needinfo?(dmarcos)
Keywords: qawanted
all combination test results as below:

only base image:
v10E   -> fine
v10F-3 -> fine

base image + pvt gaia/gecko
v10E + v1.4 gaia/gecko   -> app freeze
v10E + m-c gaia/gecko    -> app freeze
v10F-3 + v1.4 gaia/gecko -> app freeze
v10F-3 + m-c gaia/gecko  -> app freeze
Component: Vendcom → Gaia::Camera
Keywords: qawanted
Whiteboard: [flame-1.4-exploratory][POVB] → [flame-1.4-exploratory]
(In reply to Mike Lien[:mlien] from comment #15)
> all combination test results as below:
> 
> only base image:
> v10E   -> fine
> v10F-3 -> fine

I don't think that conclusively proves this isn't a vendor bug. comment 9 says that this is reproducible on 1.3 Flame, which either means you didn't test this correctly or comment 9 isn't correct.

Can we clarification on the STR used in comment 9 & resulting behavior?
Component: Gaia::Camera → Vendcom
Flags: needinfo?(psiphantong)
Whiteboard: [flame-1.4-exploratory] → [flame-1.4-exploratory][POVB]
(In reply to Jason Smith [:jsmith] from comment #16)
> (In reply to Mike Lien[:mlien] from comment #15)
> > all combination test results as below:
> > 
> > only base image:
> > v10E   -> fine
> > v10F-3 -> fine
> 
> I don't think that conclusively proves this isn't a vendor bug. comment 9
> says that this is reproducible on 1.3 Flame, which either means you didn't
> test this correctly or comment 9 isn't correct.
> 
> Can we clarification on the STR used in comment 9 & resulting behavior?

actually v10E and v10F-3 are v1.3 Flame, we don't have pvt v1.3 Flame build
so...I also wanna know why comment 9 can reproduce this issue
My mistake, this issue does not occur on the flame v10F-3 and v10E


1.3 Environmental Variables:
Device: flame 1.3 MOZ
BuildID: 20140505215459
Gaia: ec462dc62979dae593b4ad96ac3851ccbafe1813
Gecko:
Version: 28.0
Firmware Version: v10F-3

1.3 Environmental Variables:
Device: flame 1.3 MOZ
BuildID: 20140414142245
Gaia: 70d6403322ebbbc56b41ef4231e99597a92e3330
Gecko:
Version: 28.0
Firmware Version: v10E
Flags: needinfo?(psiphantong)
refer to comment 15 & comment 18, change component
Component: Vendcom → Gaia::Camera
Whiteboard: [flame-1.4-exploratory][POVB] → [flame-1.4-exploratory]
blocking-b2g: --- → 1.4?
(In reply to Mike Habicher [:mikeh] from comment #7)
> I don't think (yet) that this is a vendor bug.
> 
> Diego, can you take a look at what's going on in the Camera app? If
> everything looks fine top-side, ni? aosmond and ask him to take a look.
> He'll be picking up a Flame on Monday.

Wilson or Justin, can one of you take a quick look and see if there is any issue on the app side. Flames are going to be our primary dev/test reference device and we need to make sure apps work without freezing. 

Based on conversation with Tony yesterday, we are blocking on critical flame bugs for 1.4

Thanks
Hema
Flags: needinfo?(wilsonpage)
Flags: needinfo?(jdarcangelo)
blocking-b2g: 1.4? → 1.4+
I can reproduce this on latest master. Camera seems to freeze just after the call the mozCamera.takePicture(). Neither the success nor error callback is fired, leaving the camera UI in limbo waiting for Gecko to respond.
Flags: needinfo?(wilsonpage) → needinfo?(mhabicher)
Assignee: nobody → lmauritson
Assignee: lmauritson → nobody
QA Contact: lmauritson
Flags: needinfo?(mhabicher) → needinfo?(aosmond)
Mike is out this week

Andrew is helping investigate one
Assignee: nobody → aosmond
Target Milestone: --- → 2.0 S3 (6june)
We are unable to get a regression window in central due to the fact that the issue occurs on the earliest Central Flame build available.

Earliest Environmental Variables:
Device: Flame 2.0 MOZ
BuildID: 20140417000006
Gaia: 7591e9dc782ac2e97d63a96f9deb71c7b3588328
Gecko: e71ed4135461
Version: 31.0a1
Firmware Version: v10F-3
Investigation continues but at this point I have concluded that the take picture request gets dropped inside the driver state machine despite returning operation success. Since it is never properly started, it doesn't generate the expected callbacks to unblock the UI. Attempting to determine what has changed about our sequence of operations to put the driver into a different/bad state.
Attached patch bug1007832.patch, v1 (obsolete) — Splinter Review
Fix freeze by resetting the recording hint to false after recording. It gets set internally by the driver when the recording starts, but not clear after, and then when one requests it to take a picture, it checks this flag and changes the behaviour.
Attachment #8424908 - Flags: review?(mhabicher)
Flags: needinfo?(aosmond)
Status: NEW → ASSIGNED
Flags: needinfo?(jdarcangelo)
Fixed some organizational nits, still generate notification if parameter set fails like before
Attachment #8424908 - Attachment is obsolete: true
Attachment #8424908 - Flags: review?(mhabicher)
Attachment #8424977 - Flags: review?(dhylands)
Duplicate of this bug: 1010378
Attachment #8424977 - Flags: review?(dhylands) → review+
Blocks: 1007973
Duplicate of this bug: 1013320
May ignore test failures for Windows XP as unrelated to change
Keywords: checkin-needed
Duplicate of this bug: 999716
https://hg.mozilla.org/mozilla-central/rev/62d5b643d0ba
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
This patch depends on bug 981047, which didn't land on v1.4. Please post a branch-specific patch or get approval for that to land.
Flags: needinfo?(aosmond)
Target Milestone: 2.0 S3 (6june) → 2.0 S2 (23may)
Flags: needinfo?(aosmond)
This issue still occurs on the latest Flame build v10F-3:

1.4F Environmental Variables:
Device: Flame 1.4F MOZ
BuildID: 20140522000200
Gaia: 233dd43b3b976e66a619dbc1b4044ed1e3ca3e34
Gecko: c3c0c57daef8
Version: 30.0
Firmware Version: v10F-3
Mistake - didn't see the bug was fixed today. will check on the lasted build tomorrow. Sorry about the confusion.
You need to log in before you can comment on or make changes to this bug.