Closed Bug 1031144 Opened 11 years ago Closed 11 years ago

[Camera] unable to load camera on passcode lock screen when camera was launched before locking device

Categories

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

x86_64
Linux
defect
Not set
normal

Tracking

(blocking-b2g:1.4+, b2g-v1.4 fixed, b2g-v2.0 unaffected, b2g-v2.1 unaffected)

RESOLVED FIXED
blocking-b2g 1.4+
Tracking Status
b2g-v1.4 --- fixed
b2g-v2.0 --- unaffected
b2g-v2.1 --- unaffected

People

(Reporter: angelc04, Assigned: justindarc)

Details

(Keywords: regression)

Attachments

(2 files)

Attached file camera.log
Steps to reproduce --------------------------------------------------------------------- 1. Set screen lock and enable passcode 2. Launch Camera 3. Keep Camera running, and then Press power button to lock screen 4. Press power button again 5. Try to launch camera from Lock screen --> Camera UI keeps loading but the camera preview never appears until screen timeout. Attached is adb log. test starts: 06-27 12:00:26.423 Test build ----------------------------------------------------------------------- Gaia b51199ee4238340c9229d37e382fb399e7fb0afe Gecko https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/66f684f1a35d BuildID 20140626160219 Version 30.0 ro.build.version.incremental=82 ro.build.date=Wed Jun 25 08:52:38 CST 2014
blocking-b2g: --- → 1.4?
I did some tests and found that the first build that has this problem is: ---------------------------------------------------------------------------------------------------- Gaia 1d52323cd5b6c7d646f444712c81777d34f74e36 Gecko https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/a41052778f8d BuildID 20140623160204 Version 30.0 Last working build: ------------------------------------------------------------------------------------------------------ Gaia 3419a1f68aaf64a0688685bce42d4173b6125597 Gecko https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/34ecc9af3560 BuildID 20140622160201 Version 30.0
Keywords: regression
According to the logcat, the camera is running.
pcheng, does this problem occur on master builds? jdarc, I seem to recall something changed recently in how the lockscreen handles the camera app. Does that ring a bell?
Flags: needinfo?(pcheng)
Flags: needinfo?(jdarcangelo)
(In reply to Mike Habicher [:mikeh] from comment #3) > pcheng, does this problem occur on master builds? > > jdarc, I seem to recall something changed recently in how the lockscreen > handles the camera app. Does that ring a bell? Mike: The change was related to how we kill the secure app's process. We landed a patch on master in Bug 1019120. I can investigate this one today to see if this is the same thing. If so, we may need a v1.4 patch as well.
Flags: needinfo?(jdarcangelo)
Assignee: nobody → jdarcangelo
Summary: [dolphin][flame] unable to load camera on passcode lock screen when camera was launched before locking device → [Camera] unable to load camera on passcode lock screen when camera was launched before locking device
This is happening on all devices running v1.4, but doesn't seem to be happening on v2.0 or v2.1 (master). Still investigating.
blocking because of regression -- we should be able to load camera on a locked screen whether or not camera was launched before.
blocking-b2g: 1.4? → 1.4+
QA Contact: pcheng
Caused by patch for Bug 1024692. A runtime error was being thrown when the Camera app was hidden. Because of this, the camera hardware was not properly being released. Since launching the Camera app from the lockscreen with a passcode set requires a 2nd instance of the Camera app to be launched (in "secure mode"), the 2nd instance was hanging indefinitely while waiting for the camera hardware to become available. Clearing NI? for pcheng since this does not affect v2.0 or v2.1 (master). The patch for Bug 1024692 was landed on v1.4 only. A PR for the patch is on its way!
Flags: needinfo?(pcheng)
Attached file pull-request (v1.4)
Attachment #8447355 - Flags: review?(dmarcos)
Removing windowwanted due to cause of bug has been found.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Comment on attachment 8447355 [details] [review] pull-request (v1.4) It's ok but I have a bad feeling about keeping state that changes based on events triggered. We should rely exclusively on the events as the source of truth on the state of the app.
Attachment #8447355 - Flags: review?(dmarcos) → review+
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: