[Camera] black screen when open camera after open camera pick activity via camera

RESOLVED FIXED in 2.2 S9 (3apr)

Status

defect
--
major
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: hyuna.cho82, Assigned: mikeh)

Tracking

({regression})

unspecified
2.2 S9 (3apr)
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:2.2+, b2g-v2.0 unaffected, b2g-v2.1 wontfix, b2g-v2.2 verified, b2g-master unaffected)

Details

Attachments

(4 attachments, 1 obsolete attachment)

Reporter

Description

5 years ago
Step:
1. take a picture
2. preview - share
3. message - attach - camera
4. home key
5. reopen camera

Camera opened with black screen.
Reporter

Comment 1

5 years ago
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.
Reporter

Updated

5 years ago
Flags: needinfo?(wilsonpage)
Flags: needinfo?(dmarcos)
I am unable to reproduce (see video [1]). Am I carrying out the correct steps?

[1] http://youtu.be/qRwnRYSeeCA
Flags: needinfo?(wilsonpage)
Reporter

Comment 3

5 years ago
(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.
Reporter

Comment 4

5 years ago
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.
Flags: needinfo?(hyuna.cho82)
Also the title of the bug mentions 'lockscreen', but the lockscreen is not parts of your steps to reproduce.
Reporter

Comment 7

5 years ago
(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
Flags: needinfo?(hyuna.cho82)
Summary: [Camera] black screen when open camera from lockscreen after open pick activity via camera → [Camera] black screen when open camera after open camera pick activity via camera
comment 5
Flags: needinfo?(hyuna.cho82)
Reporter

Comment 9

5 years ago
(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.
Flags: needinfo?(hyuna.cho82)
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.
Duplicate of this bug: 1113417
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.
See Also: → 1099375
Duplicate of this bug: 1113887
[Blocking Requested - why for this release]:Bug 1113887 has been nominated as 2.1+, this case should be the same.

--
Keven
blocking-b2g: --- → 2.1?
blocking-b2g: 2.1? → 2.1+
Hi! Vincent,

Could you take a look?

--
Keven
Flags: needinfo?(vliu)
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
Keywords: qawanted
QA Contact: ktucker
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: qawanted
(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?
Flags: needinfo?(vliu) → needinfo?(hyuna.cho82)
Reporter

Comment 22

4 years ago
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.
Flags: needinfo?(hyuna.cho82)
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.
Flags: needinfo?(dmarcos)
Alive, this sounds pretty broken to me.
Component: Gaia::Camera → Gaia::System::Window Mgmt
Flags: needinfo?(alive)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga)
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.
Flags: needinfo?(alive)
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?
Flags: needinfo?(wilsonpage)
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.
Flags: needinfo?(wilsonpage) → needinfo?(alive)
(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.
Flags: needinfo?(alive)
Depends on: 892371

Comment 29

4 years ago
Triage: put this back to Camera for workaround since it's not much at window mgnt
Component: Gaia::System::Window Mgmt → Gaia::Camera

Comment 30

4 years ago
* 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
Component: Gaia::Camera → Gaia::System::Window Mgmt
Flags: needinfo?(hochang)

Updated

4 years ago
blocking-b2g: 2.1+ → 2.2?
Flags: needinfo?(hochang)

Comment 32

4 years ago
Triage: The blocking status of this bug is bounded to bug 892371. This bug can start working only after bug 892371 is fixed.
blocking-b2g: 2.2? → 2.2+

Comment 33

4 years ago
Hi Alive, I'll put you as assignee now, but we start only after bug 892371 is fixed. Thanks.
Assignee: nobody → alive
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.
Assignee: alive → nobody
Component: Gaia::System::Window Mgmt → Gaia::Camera
No longer depends on: 892371

Comment 36

4 years ago
Mike, could you help on this?
Flags: needinfo?(mhabicher)
Bug 1073017 should address this. It should be done by end of quarter.
Flags: needinfo?(mhabicher)
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.
Assignee: nobody → mhabicher
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.)
Flags: needinfo?(bchien)
Flags: needinfo?(alive)
Attachment #8580337 - Attachment is obsolete: true
Attachment #8580340 - Flags: review?(jdarcangelo)
(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.
Flags: needinfo?(alive)

Updated

4 years ago
Flags: needinfo?(bchien)
Comment on attachment 8580340 [details] [review]
[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
Attachment #8580340 - Flags: approval-mozilla-b2g37?
Comment on attachment 8580340 [details] [review]
[gaia] mikeaich:bug1102675 > mozilla-b2g:v2.2

Thanks for addressing my comments. LGTM!
Attachment #8580340 - Flags: review?(jdarcangelo) → review+
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
So, this landed on v2.2 w/o approval and also never landed on master?
Flags: needinfo?(mhabicher)
(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+?
Flags: needinfo?(mhabicher)
Flags: needinfo?(hkoka)
Flags: needinfo?(bbajaj)
Target Milestone: --- → 2.2 S9 (3apr)
(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
Flags: needinfo?(bbajaj)
Attachment #8580340 - Flags: approval-mozilla-b2g37? → approval-mozilla-b2g37+

Updated

4 years ago
Flags: needinfo?(hkoka)
Depends on: 1150445
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
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][MGSEI-Triage+]
See Also: → 1168034
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.
Flags: needinfo?(jocheng)
Hi Vance,
This is regression and only happen on 2.1 and 2.2.
Do you need the fix on 2.1S?
Thanks!
Flags: needinfo?(jocheng) → needinfo?(vchen)
Keywords: regression
Since many partners will still pick 2.1s moving forward, please help to land in on 2.1s

Thanks!
Flags: needinfo?(vchen)
You need to log in before you can comment on or make changes to this bug.