[:RJ] Reporter
	Description • 10 years ago

Description:
With camera in video mode locking the phone and opening lockscreen camera forces phone out of video mode 

Prerequisite: have lockscreen enabled  
Repro Steps:
1) Update a Flame to 20141029001202
2) Go into camera app and switch it to record video mode 
3) lock the phone, wake up the phone 
4) Switch to lock screen camera 


Actual:
Camera is in video record mode and is forced back to picture mode 

Expected:
Camera is maintained 

Environmental Variables:
Device: Flame 2.1
Build ID: 20141029001202
Gaia: eb0aab0f13c78c7ac378ad860e865c4b6eaf669f
Gecko: 318019f80a8e
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 34.0 (2.1)
Firmware Version: v188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Repro frequency:100%, 
See attached:video clip: https://www.youtube.com/watch?v=NjqFrGN6gPY

	[:RJ] Reporter
	Comment 1 • 10 years ago

was unable to grab logcat due to the way this issue is reproduced.

This issue occurs on flame 2.2 (319mb)(Kitkat Base)(Full Flash) and 2.0 (319mb)(Kitkat Base)(Full Flash)
Lockscreen camera is forced from video to picture mode 


Flame 2.2

Device: Flame 2.2 Master (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141029040208
Gaia: 35e87ac4324f0f3abd93dcc70d61c9f37256a0f5
Gecko: 7e3c85754d32
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 36.0a1 (2.2 Master)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Flame 2.0

Device: Flame 2.0 (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141029000205
Gaia: 9f5b6f025e528fabfcc068782cb9b492cb51a7f9
Gecko: de8cfd54bf93
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 32.0 (2.0)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

	Mike Habicher [:mikeh] (high bugzilla latency)
	Comment 2 • 10 years ago

Is this with a password enabled?

I'm pretty sure this is by design.

	[:RJ] Reporter
	Comment 3 • 10 years ago

there was no password enabled

	Derek Harris [:DerekH] - Dont need info. Last day 6/5/15
	Comment 4 • 10 years ago

I agree with comment 2 that this seems like it is by design. NI qa wanted owner for camera to weigh in on if this is a bug.

	No-Jun Park [:njpark]
	Comment 5 • 10 years ago

When I try the same STR, I get more serious result.  I get "Camera Unavailable - The Camera is in use by another  app" message when I enter camera from lockscreen mode.  Definitely a blocking bug.

[Blocking Requested - why for this release]:
Camera functionality compromised.  Cannot use camera if camera was used then the screen was locked before unlocking the screen.

	No-Jun Park [:njpark]
	Comment 6 • 10 years ago

Actually, what I just described above is not reproducible in 2.1.  the original issue seems by design.  I will raise a separate bug for 2.2 for the above issue.  clearing the nom.

	katieC
	Comment 7 • 10 years ago

Handing this one over to Tif, UX lead for media.

	Tiffanie Shakespeare [:tif]
	Comment 8 • 10 years ago

Camera should be retaining state (regardless of locked or unlocked) and it doesn't look like it's doing that anymore - pretty sure this is a regression, but I have no idea when it happened.

	Duane Dixon [:ddixon]
	Comment 9 • 10 years ago

The reporter tested the latest builds (2.2, 2.1, 2.0) and has listed them as "affected". 

The issue DOES occur in earliest Flame 2.2, 2.1, 2.0 builds (Full Flash, nightly, 319 MB), and appears to NOT be a regression. 

Actual Results: Camera does not maintain 'video mode' after being opened, locked, then unlocked. 

Earliest Flame 2.2

Device: Flame 2.2
BuildID: 20140917223000
Gaia: d37950eb09e28aa18d0e01df9ff90574bd4337e0
Gecko: 426497473505
Version: 35.0a1 (2.2)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0
------------------------------------------------------
Earliest Flame 2.1 B2G 34 

Device: Flame 2.1
BuildID: 20141013161204
Gaia: d51956f84ebec0dd8998654f01f9f24fe8527f51
Gecko: a0647b2686eb
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 34.0 (2.1)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
------------------------------------------------------
Earliest Flame 2.0 
20140919063017

	Tiffanie Shakespeare [:tif]
	Comment 10 • 10 years ago

Fair enough - I checked out the camera app when the phone is unlocked; the camera retains the state of video after leaving the app and returning. The same should occur when the phone is locked (both with a passcode and without). 

While testing, I noticed that the camera does actually come up in video mode when the phone is locked without a passcode, but then it automatically switches to photo mode. Subsequently, when exiting the camera app and returning, the mode is photo. 

However, when there is a passcode set, the camera comes up in photo mode (you don't see a switch). When unlocking the phone and going into camera, the mode is still set to video. 

So there's some inconsistency here - we should be staying in video regardless of locked/unlocked passcode/no passcode. 

Let me know if you need more info!

	Tiffanie Shakespeare [:tif]
	Comment 11 • 9 years ago

Is this still an issue?

	John Thomas [:Johnt]
	Comment 12 • 9 years ago

With passcode disabled: After opening Camera app and switching to video and locking and unlocking the device into camera app the user will enter the Camera app in Photo mode. 

With passcode enabled: After opening Camera app and switching to video and locking and unlocking the device into camera app the user will receive the following messaged as referenced in comment 5 "Camera Unavailable - The camera is in use by another app."

Environmental Variables:
Device: Aries 2.6 Kk
BuildID: 20151119162551
Gaia: ffaade435bb9c3005fd6c9b7ee1cd17b90e08cbf
Gecko: a523d4c7efe2f43dd6b25a176c07b729918d550f
Gonk: a19052e4389c3ae2d8fc3e7a74a475401baacc56
Version: 45.0a1 (2.6) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0

Environmental Variables:
Device: Flame 2.6 Kk Fullflash (512mb)
BuildID: 20151119030229
Gaia: cba7e4b86361af31b153cfebaf99900e0b860f7b
Gecko: 1d6155d7e6c91fa5ec1ef6927f3d3a044187896d
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 45.0a1 (2.6) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0

	John Thomas [:Johnt]
	Comment 13 • 9 years ago

My results in Comment 12 are consistent with Flame 2.5 as well. (With and without passcode.)

Environmental Variables:
Device: Flame 2.5 Kk Fullflash (512mb)
BuildID: 20151119161153
Gaia: 28d63cf3bdc4417f7ad8cab2230f096bf9f6d3b5
Gecko: 497118efc1414c2825a8bd17b38721888c3875ca
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 44.0a2 (2.5) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

	No-Jun Park [:njpark]
	Comment 14 • 9 years ago

aosmond, this is a pretty old bug, but haven't moved much.  (And the bug is still reproducible for today's build).  Should we add this for 2.6?

	Andrew Osmond [:aosmond] (he/him)
	Comment 15 • 9 years ago

The camera unavailable issue would be resolved by bug 1073017. While I don't have a bug on hand for this, in Orlando we discussed this and we will be looking at sharing the camera service code with the other platforms instead of using the patch in bug 1073017 (gcp looking into this). In any event, that should be considered a separate problem.

As for the reason why we see a switch if there is a passcode: we can't use the same instance of the app because of the security concerns (e.g. going through the preview gallery of already taken photos) so it starts a new instance, where there was no previous state to switch from. Without a passcode it can reuse it by triggering a record (image) activity -- when an activity is received, it resets the mode to the default mode for that activity (in this case picture), hence why you see a switch and it persists after unlocking the phone.

I think the way forward to fix this would be:
1) Change the system app to trigger a "record" activity with a "default" or unspecified data type instead of using "photos" under apps/system/lockscreen/js/lockscreen.js.
2) Change the camera app to accept a default/unspecified data type and to use the mode list as already ordered/selected (i.e. no need to reconfigure the mode) under apps/camera/js/controllers/activity.js.

Based on our priorities and the severity, I would say that this is not important to fix for 2.6 and could be added to the backlog.

	BMO Automation
	Comment 16 • 6 years ago

Firefox OS is not being worked on