If secure camera and camera app is both launched, camera will failed to work, and might cause Gecko to crash

RESOLVED DUPLICATE of bug 818933

Status

P1
normal
RESOLVED DUPLICATE of bug 818933
6 years ago
6 years ago

People

(Reporter: dholbert, Assigned: chiajung)

Tracking

({b2g-testdriver, smoketest, unagi})

unspecified
B2G C3 (12dec-1jan)
ARM
Gonk (Firefox OS)
b2g-testdriver, smoketest, unagi

Firefox Tracking Flags

(blocking-basecamp:+)

Details

(Whiteboard: [target:12/21])

(Reporter)

Description

6 years ago
STR:
 1. Enable a passcode lock, in Settings | Phone Lock (e.g. 1111)
 2. Tap power button twice, to get to lock screen.
 3. Slide up the lock animation, and tap the camera button.
   --> Notice that camera seems to work.
 4. Press "home" button to return to lock screen.
 5. Once again: Slide up the lock animation, and tap the camera button.

EXPECTED RESULTS: Functional camera.
ACTUAL RESULTS: Black screen, w/ still-camera & video-camera buttons missing.

Reporting using the recently-released "beta" dogfood build, w/ ID: 20121203114956
(Reporter)

Comment 1

6 years ago
(I'm guessing this might have something to do with the first instance of the lockscreen-camera-app keeping a lock on the camera hardware (in the background), as it seems to do with the GPS hardware in bug 818401)
Summary: W/ passcode lock enabled, camera won't launch from lock screen after the first time → W/ passcode lock enabled, lock-screen-launched camera is busted (black screen) after the first time it's launched.
(Reporter)

Comment 2

6 years ago
After I perform the STR, the normal camera app (launched from home screen) is broken, too.
Component: Gaia::System::Lockscreen → Gaia::Camera
Summary: W/ passcode lock enabled, lock-screen-launched camera is busted (black screen) after the first time it's launched. → W/ passcode lock enabled, camera & lockscreen-camera are both busted (black screen) after the first time lockscreen camera is launched
(Reporter)

Updated

6 years ago
OS: Linux → Gonk (Firefox OS)
Hardware: x86_64 → ARM
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 816334
blocking-basecamp: ? → ---
(Reporter)

Comment 4

6 years ago
Not a dupe of bug 816334.

That bug is about the *video* part of the camera app not taking videos (and sometimes crashing).  However, with that bug's STR, the camera app still displays whatever the camera sees.  So that bug is a video-specific thing.

This bug here is about the camera app breaking (black screen) after the first time you launch it from the lock screen.  Not video-specific -- breaks the whole app.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Reporter)

Updated

6 years ago
blocking-basecamp: --- → ?
(Reporter)

Comment 5

6 years ago
This might be fixed by bug 818401 -- bug 818401 comment 6 seems like it might confirm (& address) my suspicion in comment 1 here.
Assignee: nobody → dale
BB+, P1 - smoketest blocker
blocking-basecamp: ? → +
Keywords: smoketest
Priority: -- → P1

Updated

6 years ago
Target Milestone: --- → B2G C3 (12dec-1jan)
Whiteboard: [target:12/21]
Stealing and investigating.
Assignee: dale → timdream+bugs
STR in comment 0 is fixed by bug 818401 -- that no longer show blank screen.

However, STR in comment 1 still trigger crashes. Below is tested with latest m-c and Otoro.

STR Recap:

1. Enable Passcode lock
2. press the power button twice to go to the lock screen
3. press camera shortcut button on lock screen to use the secure camera
4. press home button to go back
5. unlock
6. launch camera app

Expect: 

1. everything works

Actual:

1. Camera failed to show the stream and soon, Gecko crashes
log: http://pastebin.mozilla.org/1989435


STR #2:

1. Enable Passcode lock
2. unlock
3. launch camera app
4. press home to go back to home screen
5. press the power button twice to go to the lock screen
6. press camera shortcut button on lock screen to use the secure camera

Expected:

1. everything works

Actual:

1. secure camera doesn't work
2. if you unlock and go to the already launched camera app, it is also broken
3. kill it and relaunch doesn't help

Note:

Secure camera lives in the System app (in-process), while Camera app is OOP'd.


This is no longer a Gaia issue.
Assignee: timdream+bugs → nobody
Component: Gaia::Camera → General
Summary: W/ passcode lock enabled, camera & lockscreen-camera are both busted (black screen) after the first time lockscreen camera is launched → If secure camera and camera app is both launched, camera will failed to work, and might cause Gecko to crash
Gaia is doing an unsupported thing with a certified API.

Dale, did you explain why we have to have two different apps here?  I still don't understand.  Why can't we launch the camera app?
Looks like a dup of bug 818933?
(Assignee)

Comment 11

6 years ago
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #8)
> STR in comment 0 is fixed by bug 818401 -- that no longer show blank screen.
> 
> However, STR in comment 1 still trigger crashes. Below is tested with latest
> m-c and Otoro.
> 
> STR Recap:
> 
> 1. Enable Passcode lock
> 2. press the power button twice to go to the lock screen
> 3. press camera shortcut button on lock screen to use the secure camera
> 4. press home button to go back
> 5. unlock
> 6. launch camera app
I tried to port WebRTC capture these days, and found a similar symptom. I think the problem is:

12-13 14:40:04.066   433   450 E CAM_FD  : cam_conf open driver failed: device =/dev/msm_camera/config0: Device or resource busy!

In step 3, it will allocate the camera device via dom/camera API's from gecko process. Which will trigger android::CameraHardwareInterface to open the hardware module. However, there is no hint for it to release the hardware handle when leave. As a result, you can still launch the camera from lock screen even if the camera app launch failed, but /*no other*/ process will have any means to open camera. 

In fact, I think you can repro it by:
1. Enable Passcode lock
2. Launch camera app
3. Go to lockscreen
4. Launch camera from lockscreen

Since camera app do not release camera device, too.
(Assignee)

Comment 12

6 years ago
As a result, I think an easy fix would be

1. Add Terminate camera to nsIDOMCamera interface
2. In Terminate, release all hardware resource
3. When camera app leaves, let it calls the Terminate to release hardware resources

By the way, I think such change must affect the init/start preview sequence of camera app.
(Assignee)

Updated

6 years ago
Assignee: nobody → chung
(Assignee)

Comment 13

6 years ago
Hmm...I found I may wrong...

This would be hard to fix from gecko side. Since dom/camera implementation lock up the camera as soon as the GonkCameraControl got initialized.

An easy workaround would be that releasing camera control from app side when it becomes invisible, and reconstruct it when visibility state goes from invisible to visible.
(In reply to Chiajung Hung [:chiajung] from comment #13)
> Hmm...I found I may wrong...
> 
> This would be hard to fix from gecko side. Since dom/camera implementation
> lock up the camera as soon as the GonkCameraControl got initialized.
> 
> An easy workaround would be that releasing camera control from app side when
> it becomes invisible, and reconstruct it when visibility state goes from
> invisible to visible.

Yes, if you think that make sense more than having a platform fix on the this bug, please change the component and reassign to me. We have the same issue with multiple camera app instance. See bug 816331 comment 10.
(Assignee)

Comment 15

6 years ago
After(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #14)
> (In reply to Chiajung Hung [:chiajung] from comment #13)
> > Hmm...I found I may wrong...
> > 
> > This would be hard to fix from gecko side. Since dom/camera implementation
> > lock up the camera as soon as the GonkCameraControl got initialized.
> > 
> > An easy workaround would be that releasing camera control from app side when
> > it becomes invisible, and reconstruct it when visibility state goes from
> > invisible to visible.
> 
> Yes, if you think that make sense more than having a platform fix on the
> this bug, please change the component and reassign to me. We have the same
> issue with multiple camera app instance. See bug 816331 comment 10.

I tried to set the Camera._cameraObj to null when visibility change, but it not work. Since the object do not released in gecko layer until GC (correct me if I am wrong).

I will try to add some explicitly termination call to nsIDOMCameraControl, and fix the GonkCameraControl implementation.
(In reply to Chiajung Hung [:chiajung] from comment #15)
> After(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #14)
> > 
> > Yes, if you think that make sense more than having a platform fix on the
> > this bug, please change the component and reassign to me. We have the same
> > issue with multiple camera app instance. See bug 816331 comment 10.
> 
> I tried to set the Camera._cameraObj to null when visibility change, but it
> not work. Since the object do not released in gecko layer until GC (correct
> me if I am wrong).
> 
> I will try to add some explicitly termination call to nsIDOMCameraControl,
> and fix the GonkCameraControl implementation.

As a doomsday workaround, we could |window.close()| the Camera app if it finds itself to be at the background.... that would be like the old-school |hackKillMe| :-P
Duplicate of this bug: 818933
(In reply to Chiajung Hung [:chiajung] from comment #15)
> After(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #14)
> > (In reply to Chiajung Hung [:chiajung] from comment #13)
> > > Hmm...I found I may wrong...
> > > 
> > > This would be hard to fix from gecko side. Since dom/camera implementation
> > > lock up the camera as soon as the GonkCameraControl got initialized.
> > > 
> > > An easy workaround would be that releasing camera control from app side when
> > > it becomes invisible, and reconstruct it when visibility state goes from
> > > invisible to visible.
> > 
> > Yes, if you think that make sense more than having a platform fix on the
> > this bug, please change the component and reassign to me. We have the same
> > issue with multiple camera app instance. See bug 816331 comment 10.
> 
> I tried to set the Camera._cameraObj to null when visibility change, but it
> not work. Since the object do not released in gecko layer until GC (correct
> me if I am wrong).
> 
> I will try to add some explicitly termination call to nsIDOMCameraControl,
> and fix the GonkCameraControl implementation.

I already have a patch to do this; am still testing it.
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 818933
You need to log in before you can comment on or make changes to this bug.