Closed Bug 1073208 Opened 10 years ago Closed 10 years ago

[Camera] Taking photos in rapid succession results in a static image

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:-, b2g-v2.0 affected, b2g-v2.1 affected, b2g-v2.2 affected)

RESOLVED WONTFIX
blocking-b2g -
Tracking Status
b2g-v2.0 --- affected
b2g-v2.1 --- affected
b2g-v2.2 --- affected

People

(Reporter: rpribble, Assigned: aosmond)

References

()

Details

(Whiteboard: [2.1-Daily-Testing])

Attachments

(1 file)

Description:
If the user taps the camera button rapidly to take multiple photos in a row, the image on the camera screen will remain unchanged and static, but the photos displayed in the preview gallery will show a different image.
   
Repro Steps:
1) Update a Flame device to BuildID: 20140924000243
2) Slide lock screen to left to use the camera (or navigate to camera)
3) Tap the camera button repeatedly to keep taking photos
4) Observe the camera screen while the photos are being taken
5) Tap the preview gallery button
6) Observe the photos that were taken
  
Actual:
Rapid photo-taking results in a static image on the camera screen but different images taken in the gallery.
  
Expected: 
Camera view never remains static.
  
Environmental Variables:
Device: Flame 2.1 
BuildID: 20140924000243
Gaia: 93a99bea0b40d81bd063f7d8b1964dc1ba35ba7b
Gecko: d7e31ecd48af
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
  
Notes:
  
Repro frequency: 90%
See attached: Video, logcat
Attached file Logcat.txt
Adding qawanted for branch checks. Thank you!
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: qawanted
This bug repro's on Flame KK builds: Flame 2.2 KK, Flame 2.1 KK, Flame 2.0 KK, Flame 2.0 Base KK

Actual Results: Rapidly tapping on the camera shutter buttons takes different photos but the image you see in the camera view screen doesn't change.

Repro Rate: 12/12

Environmental Variables:
Device: Flame Master KK
BuildID: 20140925134737
Gaia: a06714c555ca7068545f10b4437a16c14cd8e7f5
Gecko: 9e3d649b80a2
Version: 35.0a1 (Master) 
Firmware Version: L1TC10011800
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0
-----------------------------------------------------------------
Environmental Variables:
Device: Flame 2.1 KK
BuildID: 20140926071340
Gaia: 9ebd12fb519dd675ff04f7c6298522a40d92e6d7
Gecko: 2b181f0523c8
Version: 34.0a2
Firmware Version: L1TC10011800
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
-----------------------------------------------------------------
Environmental Variables:
Device: Flame 2.0 KK
BuildID: 20140926071941
Gaia: c1aa7829548e65360472c31544dbe2839eaf5be1
Gecko: 61d78a6855fb
Version: 32.0 (2.0) 
Firmware Version: L1TC10011800
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
-----------------------------------------------------------------
Device: Flame 2.0 Base KK
BuildID: 20140904160718
Gaia: 506da297098326c671523707caae6eaba7e718da
Gecko: 
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?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Contact: croesch
[Blocking Requested - why for this release]: broken functionality in a major feature (Camera) - the view on the screen is not representational of what the picture taken is.
blocking-b2g: --- → 2.0?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Blocking Reason: This is an pretty intense case of rapidly tapping on camera icon. Moving out of blocking nom. Andrew will be investigating however after other high priority bugs are fixed. Leaving an NI on him
blocking-b2g: 2.0? → -
Flags: needinfo?(aosmond)
Assigning to Andrew for investigation.
Assignee: nobody → aosmond
Testing shows that the camera driver is busy (presumably taking the pictures) and isn't actually sending us new preview frames. Bug 1034074 is supposed to create a rate limiting solution for attributes (and APIs presumably from discussions with justindarc) to prevent this sort of hammering. Once that is in place, we should not see static images in the UI as observed with these STR.
Depends on: 1034074
Flags: needinfo?(aosmond)
Andrew confirmed in IRC that all of the taken pictures are correct; it's just the preview which is frozen at whatever was showing when the shutter-button-hammering started.

This is a function of the camera driver, which stops the preview stream while taking pictures. If we take enough pictures in rapid succession, the viewfinder will not get to start, and the screen will not update.
Working as expected.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
QA Contact: croesch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: