Step: 1. take a picture 2. preview - share 3. message - attach - camera 4. home key 5. reopen camera Camera opened with black screen.

When press home key, camera is in background and close preview gallery. When open camera again, camera app request getting camera and pick activity also request in this case.

I am unable to reproduce (see video [1]). Am I carrying out the correct steps? [1] http://youtu.be/qRwnRYSeeCA

(In reply to Wilson Page [:wilsonpage] from comment #2) > I am unable to reproduce (see video [1]). Am I carrying out the correct > steps? > > [1] http://youtu.be/qRwnRYSeeCA I can't play the video although sing in. It seems that I don't have permission to show.

I just saw video file. It's incorrect steps. camera - capture - preview gallery - share - message - attach in sms - camera(pick activity) - home key - open camera again. you can see black screen.

(In reply to hyuna.cho from comment #4) > I just saw video file. > It's incorrect steps. > > camera - capture - preview gallery - share - message - attach in sms - > camera(pick activity) - home key - open camera again. > > you can see black screen. I don't understand what 'camera(pick activity)' means.

Also the title of the bug mentions 'lockscreen', but the lockscreen is not parts of your steps to reproduce.

(In reply to Wilson Page [:wilsonpage] from comment #6) > Also the title of the bug mentions 'lockscreen', but the lockscreen is not > parts of your steps to reproduce. sorry. I confused other issue. I changed it

(In reply to Wilson Page [:wilsonpage] from comment #5) > (In reply to hyuna.cho from comment #4) > > I just saw video file. > > It's incorrect steps. > > > > camera - capture - preview gallery - share - message - attach in sms - > > camera(pick activity) - home key - open camera again. > > > > you can see black screen. > > I don't understand what 'camera(pick activity)' means. when click attach in sms you can select camera. I know that's pick activity.

I *can* reproduce: 1. Take picture 2. Go to preview gallery 3. Share picture with 'Messages' app 4. Tap the paperclip button to attach another picture 5. Press the 'home' button 6. Open the Camera app from the homescreen Actual: 'Camera hardware in use by another application' overlay Expected: Camera should work as normal

This indicates that at some stage in the process the Camera hardware is not being released. We need to dive deeper into this and do some logging. Although IIRC it's not possible to debug apps spawned from an activity with WebIDE.

Per bug 1099375, there's a problem with the camera driver where it lets us open the front and back cameras in separate apps, even though the hardware/driver doesn't really support it. THAT part needs to be fixed in the driver. One day, I also hope we'll have the ability to send visibility events to pick activities so that we can close the camera instance in step 5 in comment 10.

[Blocking Requested - why for this release]:Bug 1113887 has been nominated as 2.1+, this case should be the same. -- Keven

Hi! Vincent, Could you take a look? -- Keven

Sure.

I can't reproduce this issue by Comment 10 using the latest v2.1 on Flame. Does anyone can confirm with that? Thanks.

Need QA to confirm with comment 18. Thanks -- Keven

I am not getting a black screen but i am seeing the overlay "The camera is in use by another app" overlay when following the steps in comment 10. STR 1. Open camera. 2. Take a picture. 3. Tap on the preview of the picture which is in the circle. 4. Tap the "share" button and select "messages". 5. Tap the "paperclip" and select "Camera". 6. While in the camera, tap the "home button". 7. Tap on the "Camera" app to open camera again. Actual: The user is shown the overlay "The camera is in use by another app". Environmental Variables: Device: Flame 2.1 BuildID: 20150120001202 Gaia: 77c57eb8a985d5cbd34a597fb1b978ba6e205af6 Gecko: f05d0a2d2378 Version: 34.0 (2.1) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

(In reply to KTucker [:KTucker] from comment #20) > I am not getting a black screen but i am seeing the overlay "The camera is > in use by another app" overlay when following the steps in comment 10. > > STR > > 1. Open camera. > 2. Take a picture. > 3. Tap on the preview of the picture which is in the circle. > 4. Tap the "share" button and select "messages". > 5. Tap the "paperclip" and select "Camera". > 6. While in the camera, tap the "home button". > 7. Tap on the "Camera" app to open camera again. > > Actual: > The user is shown the overlay "The camera is in use by another app". > > Environmental Variables: > Device: Flame 2.1 > BuildID: 20150120001202 > Gaia: 77c57eb8a985d5cbd34a597fb1b978ba6e205af6 > Gecko: f05d0a2d2378 > Version: 34.0 (2.1) > Firmware Version: v18D-1 > User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 I can also see "The camera is in use by another app" when I try this method. May I confirm that the issue is the same?

I filed this bug after check it in v2.0 branch and I checked this in v2.1 branch. In v2.1 branch, show "The camera is in use by another app" message when follow STR of comment 10. I think it seems fix. But I have question. Message app opened via "share" button in camera app, so message app doesn't exist in card view. But message say "The camera is in use by another app". Is it OK? 1. Open camera. 2. Take a picture. 3. Tap on the preview of the picture which is in the circle. 4. Tap the "share" button and select "messages". 5. Tap the "paperclip" and select "Camera". 6. While in the camera, tap the "home button". 7. Tap on the "Camera" app to open camera again. 8. Long press the "home button" to show card view. --> only Camera app is in there.

I've had some time to investigate, this is what I think is happening: 1. Camera app is launched (Camera1) 2. Camera spawns SMS app with 'inline' activity (camera never receives `visibilitychange` event) 3. SMS spawns new Camera app (Camera2) with 'inline' activity 4. System gets confused about which of the two Camera apps is open 5. Camera 2 SMS is minimised (via home key) 6. Both Camera1 and Camera2 receive `visibilitychange` event 7. Camera2 is opened 8. Both Camera1 and Camera2 receive `visibilitychange` event, causing both apps to request mozCamera hardware. 9. Camera1 gets the hardware before Camera2 and Camera2 correctly displays 'Camera in use by another app' overlay. --- I'm not familiar with how the app *should* behave under this scenario, but something at the System level is wrong. Camera1 should not be receiving `visibilitychange` events for Camera2. There's nothing Camera app can do to defend against this.

Alive, this sounds pretty broken to me.

If I didn't misunderstand, the problem is https://bugzilla.mozilla.org/show_bug.cgi?id=892371 The flow as Wilson stated is: Camera app -> sms activity -> camera activity. All of these three iframes will be foreground and go to background at the same time when press home button. We have difficulty to fix this in system side because of bug 892371.

I am calling this 'circular activity' and we have no idea how to fix - it's hard to say it is wrong to invoke activity to itself. My suggestion would be calling window.close() while the camera activity is foreground but you cannot get the mozCamera resource. One another way is use BroadcastChannel API by https://bugzilla.mozilla.org/show_bug.cgi?id=966439 to notify camera app the camera activity is requesting the mozCamera so please release the hardware. And yes this is a workaround. What do you think?

To me it seems fundamentally broken for an app to report itself as 'visible' (`!document.hidden`) when it is 'hidden' and should be inactive. In the flow 'Camera1 -> SMS -> Camera2' what would happen if Camera1 called `window.close()` when Camera2 was opened? When the activity chain unravels back to the source (Camera1) would the app be hidden? Yes, we could probably find a workaround for this in Camera, but it's a symptom of a larger problem that will likely surface again.

(In reply to Wilson Page [:wilsonpage] from comment #27) > To me it seems fundamentally broken for an app to report itself as 'visible' > (`!document.hidden`) when it is 'hidden' and should be inactive. > You could push bug 892371 - I'd raised it many times.

Triage: put this back to Camera for workaround since it's not much at window mgnt

* not much we can do at window mgnt

Diego has been investigating this and it is tricky to put in a workaround on the camera side (broadcast api is not an option as it is not available in 2.1). Also looks like it is a not common steps to reproduce. Can we push to get the proper platform fix on master/2.2 instead of tricky hacks. Thanks Hema

Triage: The blocking status of this bug is bounded to bug 892371. This bug can start working only after bug 892371 is fixed.

Hi Alive, I'll put you as assignee now, but we start only after bug 892371 is fixed. Thanks.

I am going to deassign myself because: bug 892371's fix does not fit our request; we still needs the activity opener to be foreground. Therefore we can't apply the patch in comment 34 here in system app otherwise the device will become unstable while do activity works. So, here is my suggestion: * Use localStorage to communicate camera app and camera activity in v2.2 * Use broadcastChannel to communicate camera pp and camera activity in master BTW, even with the patch in comment 34, when exiting the sms activity, you will still see the camera app has a 'Camera hardware in use by another application' overlay which I think it's a camera issue.

Mike, could you help on this?

Bug 1073017 should address this. It should be done by end of quarter.

I just tried to reproduce this with: Gaia-Rev 738987bd80b0ddb4ccf853855388c2627e19dcc1 Gecko-Rev https://hg.mozilla.org/mozilla-central/rev/008b3f65a7e0 Build-ID 20150317073344 Version 39.0a1 Device-Name flame FW-Release 4.4.2 FW-Incremental 65 FW-Date Mon Dec 15 18:51:29 CST 2014 Bootloader L1TC000118D0 ...and was unable to. The relaunched Camera app starts just fine.

With this build: Gaia-Rev d0e09d5e6367e558824f9cbf691da99cedf63037 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/793d61bb0bd4 Build-ID 20150317002504 Version 37.0 Device-Name flame FW-Release 4.4.2 FW-Incremental 65 FW-Date Mon Dec 15 18:51:29 CST 2014 Bootloader L1TC000118D0 ...I *do* see the "The camera is in use by another app" error message. Except it isn't -- logcat shows the hardware is successfully opened by the app and generating preview frames.

v2.1 shows the same behaviour as in comment 39, but with the addition of the camera-with-a-line-through-it icon: Gaia-Rev e53469fe3a5e563a9146d0fb028e544a423b7e96 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/32d1cae787e0 Build-ID 20150317001200 Version 34.0 Device-Name flame FW-Release 4.4.2 FW-Incremental 65 FW-Date Mon Dec 15 18:51:29 CST 2014 Bootloader L1TC000118D0 As with v2.2/b2g37, the logcat shows the camera hardware open and running.

Alive, Bobby -- what is the difference between v3.0 and v2.2 that makes this work in the latter version? (See comment 38 and comment 39.)

(In reply to Mike Habicher [:mikeh] from comment #41) > Alive, Bobby -- what is the difference between v3.0 and v2.2 that makes this > work in the latter version? (See comment 38 and comment 39.) It's timing issue. This should depend on when mozCamera is blocked by your request. When launching camera app we will bring camera app and message activity/camera activity to foreground at the same time; this is async so it depends on who wins the battle, camera app or camera activity.

Comment on attachment 8580340 [details] [gaia] mikeaich:bug1102675 > mozilla-b2g:v2.2 NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings. [Approval Request Comment] Bug caused by (feature/regressing bug #): bug 1102675 User impact if declined: reopening the Camera app while into an attach-from-Camera activity will trigger a race for the hardware that the activity almost always loses, causing the user to see "Camera hardware is already in use" error Testing completed: STR in this bug Risk to taking this patch (and alternatives if risky): low String or UUID changes made by this patch: none

Comment on attachment 8580340 [details] [gaia] mikeaich:bug1102675 > mozilla-b2g:v2.2 Thanks for addressing my comments. LGTM!

Pull request has landed in v2.2: https://github.com/mozilla-b2g/gaia/commit/e54c4ed1cc188f70ddf1156534d364005dc45490

So, this landed on v2.2 w/o approval and also never landed on master?

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #48) > So, this landed on v2.2 w/o approval and also never landed on master? Sorry -- I didn't expect 'checkin-needed' to autoland with a+. This fix is only for 2.2. m-c/master is unaffected. bhavana, hema: can we get a retroative a+?

(In reply to Mike Habicher [:mikeh] from comment #49) > (In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #48) > > > So, this landed on v2.2 w/o approval and also never landed on master? > > Sorry -- I didn't expect 'checkin-needed' to autoland with a+. This fix is > only for 2.2. m-c/master is unaffected. > > bhavana, hema: can we get a retroative a+? approving, this for 2.2

This bug has been verified as pass on latest Nightly build of Flame v2.2 and Nexus 5 v2.2 by the STR in Comment 0 & Comment 10. Actual results: There is no black screen and no prompt "Camera hardware in use by another application" in Camera, and Camera can be used normally. See attachment: verified_v2.2.mp4 Reproduce rate: 0/6 Device: Flame v2.2 build(Pass) Build ID 20150601002502 Gaia Revision b4582cc394e0919623263997c0cdb0b4751a1403 Gaia Date 2015-05-31 11:06:34 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/78d8b0a4303d Gecko Version 37.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150601.040105 Firmware Date Mon Jun 1 04:01:17 EDT 2015 Bootloader L1TC000118D0 Device: Nexus 5 v2.2 build(Pass) Build ID 20150601002502 Gaia Revision b4582cc394e0919623263997c0cdb0b4751a1403 Gaia Date 2015-05-31 11:06:34 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/78d8b0a4303d Gecko Version 37.0 Device Name hammerhead Firmware(Release) 5.1 Firmware(Incremental) eng.cltbld.20150601.035851 Firmware Date Mon Jun 1 03:59:06 EDT 2015 Bootloader HHZ11k

Hi Josh, This bug can't be repro on latest Flame v2.0 by the STR in comment 10, so it should be a regression. Please help to confirm whether it will approval to v2.1? Thank you very much. --------------------------------------------------------------------------------------------------- Actual results (v2.0): After re-opening the Camera app, it does not show black screen or prompts "Camera Unavailable", it remains the camera photographed view that you can capture a new picture. See attachment: video_v2.0.3gp. Rate: 0/10. Device: Flame v2.0 build(unaffected) Build ID 20150617160205 Gaia Revision 5552bf529d3d6775a968942e9afa6c1d4037362c Gaia Date 2015-05-21 14:42:19 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/d78115b1ed80 Gecko Version 32.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150617.192814 Firmware Date Wed Jun 17 19:28:26 EDT 2015 Bootloader L1TC000118D0

Hi josh, Please see comment 53, thanks.

Hi Vance, This is regression and only happen on 2.1 and 2.2. Do you need the fix on 2.1S? Thanks!

Since many partners will still pick 2.1s moving forward, please help to land in on 2.1s Thanks!