Closed Bug 1042028 Opened 10 years ago Closed 10 years ago

[KK Only][QRD]Black Camera preview when opened through gallery or lockscreen, provided camera was open in background

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
major

Tracking

(blocking-b2g:2.0+)

RESOLVED WORKSFORME
blocking-b2g 2.0+

People

(Reporter: poojas, Unassigned)

References

Details

(Whiteboard: [caf priority: p2][CR 698568])

Attachments

(2 files)

1. Complete black preview observed on Camera when we open the camera from Gallery.
  STR:  
  1. Open camera.
  2. Take some pictures or record some videos.
  3. Go to gallery.
  4. Open the camera again from gallery app and observe an issue.

  Also Note: Only preview is black but it takes user input and if we switch  
  to camcorder mode then there preview is okay
  Reproducibility: 5/5 times

2. Complete device screen goes black when open camera via lockscreen provided camera was open before on background

  STR
    1. Enable Screen lock via Settings app
    2. Open camera app
    3. Press power button to send device in suspend
    4. Press Power button to resume it back
    5. Open camera app again via lockscreen

    Observe complete black screen. None of the camera UI elements were displayed
   
Both of these issue looks similar i.e when camera app opened in background and gallery/lockscreen tries to open camera  then its preview becomes black

Found Bug 988610 Which has similar issue but with little different test case.
Also : https://bugzilla.mozilla.org/show_bug.cgi?id=988610#c7
[Blocking Requested - why for this release]:
blocking-b2g: --- → 2.0?
Target : 2.0 Flame and QRD 8x10 both
This sounds a lot like bug 1036312, a patch for which landed on 2.0 on July 14th. Please confirm what version of code you're running (in general, please always include this in your bug reports).
Flags: needinfo?(poojas)
(In reply to Mike Habicher [:mikeh] from comment #3)
> This sounds a lot like bug 1036312, a patch for which landed on 2.0 on July
> 14th. Please confirm what version of code you're running (in general, please
> always include this in your bug reports).

I'll also mark qawanted here to see if one of our guys can reproduce this on the latest 2.0.
Keywords: qawanted
Unable to reproduce on today's Flame 2.0.  After following both sets of repro steps the camera shows a black screen for a second or two before showing the viewfinder preview.

Build ID: 20140722000200
Gaia: b9d19011123487009c80d1200937652d58c434a0
Gecko: 00f4b3a7046f
Platform Version: 32.0
Firmware Version: v122
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: ckreinbring
No repro on Flame - we do not have a 8x10 QRD device to verify but it seems like this might be fixed based on comment 3 and comment 5
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
No repro on Open 2 either using:

Gaia   b9d19011123487009c80d1200937652d58c434a0
SourceStamp 00f4b3a7046f
BuildID 20140722000200
Version 32.0
(In reply to Mike Habicher [:mikeh] from comment #3)
> This sounds a lot like bug 1036312, a patch for which landed on 2.0 on July
> 14th. Please confirm what version of code you're running (in general, please
> always include this in your bug reports).

Patch for bug 1036312 is already in below build , in which issue reproduced

Build details : 
Device QRD 8x10 KK based 2.0 

"gaia 5f8b1b8a2da9e3b531eee817a669f57fa4d9b9c6"
"gecko e00f7e464333689fcf54edb4945ece94f97f930b"
Version 32.0a2
Build Id 20140717155308

Also attaching recorded video of issue.
Flags: needinfo?(poojas)
blocking-b2g: 2.0? → 2.0+
With the video included here - are we able to reproduce the bug now?
Keywords: qawanted
 Video links from dropbox are erroring out with 500 right now (one of the videos worked a few mins back)
(In reply to Jason Smith [:jsmith] from comment #11)
> With the video included here - are we able to reproduce the bug now?

Using the latest nightly v2.0 build, I am unable to reproduce on a 512 MB Flame. Followed the STR from the attached videos.

Gaia      8cb1a949f2e9650bb2c5598e78a6f24a58bbaf97
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/4bd4b0ae7bbe
BuildID   20140721000201
Version   32.0a2
Summary: Black Camera preview when opened through gallery or lockscreen, provided camera was open in background → [KK Only][QRD]Black Camera preview when opened through gallery or lockscreen, provided camera was open in background
Whiteboard: [CR 698568]
Whiteboard: [CR 698568] → [caf priority: p2][CR 698568]
Brian will try to reproduce this bug.
Mike, could you check this? We have one QRD. thank you.
Flags: needinfo?(mlien)
QRD build currently encounter camera cannot launch successfully issue, keep waiting to reply
(In reply to Jason Smith [:jsmith] from comment #11)
> With the video included here - are we able to reproduce the bug now?

Unable to reproduce the issue following the two videos on a 7/22 build (when this bug was originally filed).
Repro rate: 0/5 for comment 9's video, and 0/3 for comment 10's video.

Tested on:
Device: Flame (319MB mem)
Build ID: 20140722093056
Gaia: b9d19011123487009c80d1200937652d58c434a0
Gecko: f6eced22c26c
Version: 32.0 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
Blocks: CAF-v2.0-CC-metabug
No longer blocks: CAF-v2.0-FC-metabug
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Justin: Like bug 1036814, this is marked as kit-kat only. Does it sound familiar to you at all from Nexus 4 days?  If you have a nexus 4 running kit-kat can you try to reproduce on that device?

Mike: do you know what has changed in the Android API between JB and KK, particularly in the code for acquiring and releasing the camera preview stream?

The fact that this happens when the camera re-opens makes me think that something is failing in the visibilitychange event handler either when we go to sleep or when we wake up again. If an exception is being thrown and not handled in that event handler on KK, that could cause the behavior that is reported.  We really need someone who can reproduce this and can also insert some JavaScript logging statements into the code to see what is going on.

Pooja: is there anyone at CAF who could team up with Justin or one of our other Gaia camera developers to figure out where the failure is happening?  We can't reproduce but we can provide debugging suggestions if you've got someone who can try out those suggestions and report back.
Flags: needinfo?(poojas)
Flags: needinfo?(mhabicher)
Flags: needinfo?(jdarcangelo)
Pooja,

Here's another question for you in addition to the one in comment 18...

After watching the videos you attached, I'd be very interested to know whether the black viewfinder bug reproduces if you:

1) Open camera app
2) Take a picture
3) Preview the picture by tapping on the circle in to the left of the shutter button
4) Use the back button (or whatever it is) to return to the camera
5) Do you get a viewfinder here, or is it black?

Previewing a photo and returning to the camera should (I think) release and reacquire the camera hardware in the same way that going to gallery and back to camera should, so it would be very interesting to know if the same bug occurs in that situation.
It seems strange to me that the symptom of locking and unlocking the screen (a complete black screen) is different than the symptom of leaving and re-entering the camera app (a black viewfinder, with controls still visible).

When I first read the STR, I thought it was referring to a lockscreen locked with a PIN, and figured that the different symptoms were because the camera run from a PIN locked screen is so different. But when watching the video I see that it is just the regular no-PIN lockscreen and we're just opening the camera app then locking and unlocking the screen.

I can't see why this would be any different. It is either a big clue to the nature of the bug, or a big red herring and the lockscreen issue is some separate bug.
(In reply to David Flanagan [:djf] from comment #20)
> It seems strange to me that the symptom of locking and unlocking the screen
> (a complete black screen) is different than the symptom of leaving and
> re-entering the camera app (a black viewfinder, with controls still visible).
> 
> When I first read the STR, I thought it was referring to a lockscreen locked
> with a PIN, and figured that the different symptoms were because the camera
> run from a PIN locked screen is so different. But when watching the video I
> see that it is just the regular no-PIN lockscreen and we're just opening the
> camera app then locking and unlocking the screen.
> 
> I can't see why this would be any different. It is either a big clue to the
> nature of the bug, or a big red herring and the lockscreen issue is some
> separate bug.

I don't think this is a lockscreen issue because Comment 0 also mentions re-launching Camera from the Gallery app (no mention of lockscreen).
(In reply to David Flanagan [:djf] from comment #18)

> Mike: do you know what has changed in the Android API between JB and KK,
> particularly in the code for acquiring and releasing the camera preview
> stream?

There are a few small changes in the AOSP camera API between JB and KK (search for ANDROID_VERSION in [1]), but nothing that would work once then not work a second time. And we abstract those differences away before they get any higher.

It would be handy to get a logcat, preferably from a build with this line[2] changed to read:

#define DOM_CAMERA_LOG( type, ... ) printf_stderr(__VA_ARGS__)

1. http://dxr.mozilla.org/mozilla-central/source/dom/camera/GonkCameraHwMgr.cpp
2. http://dxr.mozilla.org/mozilla-central/source/dom/camera/CameraCommon.h#28
Flags: needinfo?(mhabicher)
This issue is resolved in latest builds. So closing this bug now. Will reopen if see this again

build id: 20140729184534
gaia = 0a864988f5dce7f9f3dea9609e8ef054679c30ff
gecko = 745b486db495248e4d4503039e374cb8d5bb244f
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(poojas)
Resolution: --- → FIXED
Flags: needinfo?(mlien)
Resolution: FIXED → WORKSFORME
Flags: needinfo?(jdarcangelo)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: