846262 - [OPEN_][camera]camera can not use when do some operations in contacts.(617002041478)

Status: VERIFIED FIXED

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

Description

[Firefox_Mozilla]

Steps to reproduce:
1.Go into contacts;
2.create a new contact and tap “Add Picture”;
3.select from camera;
4.in camera view interface, press power key to lock screen;
5.press power key to wake up and tap “camera” in lock screen;
Expected results:
1.it can go into camera and take a photo;
Actual results:
1.it can go into camera but the interface is shown black.

Comment 1

[Kai-Chih Hu [:khu]]

QA will verify this issue.

Comment 2

[Mike Habicher [:mikeh] (high bugzilla latency)]

Attachment: logcat from STR

Comment 3

[Mike Habicher [:mikeh] (high bugzilla latency)]

The logcat in comment 2 is from following the STR above.  In this case, my Unagi eventually lands back on the "Add contact" screen, not the camera; the logcat shows a stalled camera preview.

Also, the camera preview continued to run while the screen was turned off.

Comment 4

[Mike Habicher [:mikeh] (high bugzilla latency)]

Also, the logcat shows:

D(  108:0xf6)  Out of PMEM. Dumping PMEM stats for debugging
D(  108:0xf6)  ------------- PRINT PMEM STATS --------------
D(  108:0xf6)  Node 0 -> Start Address : 0 Size 19200 Free info 0
D(  108:0xf6)  Node 1 -> Start Address : 19200 Size 19200 Free info 0
D(  108:0xf6)  Node 2 -> Start Address : 38400 Size 19200 Free info 0
D(  108:0xf6)  Node 3 -> Start Address : 57600 Size 6912 Free info 0
D(  108:0xf6)  Node 4 -> Start Address : 64512 Size 12288 Free info 1
D(  108:0xf6)  Node 5 -> Start Address : 76800 Size 19200 Free info 0
D(  108:0xf6)  Node 6 -> Start Address : 96000 Size 55040 Free info 1
D(  108:0xf6)  Node 7 -> Start Address : 151040 Size 2560 Free info 0
D(  108:0xf6)  Node 8 -> Start Address : 153600 Size 2560 Free info 0
D(  108:0xf6)  Node 9 -> Start Address : 156160 Size 76800 Free info 0
D(  108:0xf6)  Node 10 -> Start Address : 232960 Size 29184 Free info 1
D(  108:0xf6)  Total Allocated: Total Free: 
D(  108:0xf6) ----------------------------------------------
E(  108:0xf6) /dev/pmem: No more pmem available
W(  108:0xf6) Falling back to ashmem

Comment 5

[Mike Habicher [:mikeh] (high bugzilla latency)]

It looks like what's happening is:
- open Contacts app
- add a new contact
- tap on Add Image
- choose Camera in the activities picker
- camera opens
- tap Power button
---> camera continues to run in the Contacts app context
- tap Power button again
- tap Camera icon
---> Camera app isn't running on its own, so Lockscreen starts a new instance
- camera activity is no longer in the foreground
---> visibilitychange event releases the camera hardware
- new Camera instance starts the preview
---> 5 preview frames are produced, but never freed, so the preview thread stalls ("Try again")

At this point, using the Task Switcher to switch back to the Camera app resumes the preview correctly.

Comment 6

[Mike Habicher [:mikeh] (high bugzilla latency)]

Follow-up to comment 5: with the regular Camera app running, pressing the power button correctly stops the preview and releases the camera hardware.  This is correct behaviour.

So there's a problem receiving visibility events in activities.

Comment 7

[Mike Habicher [:mikeh] (high bugzilla latency)]

Note, the above is observed on Unagi with:
- gecko: inbound-src:33a198f5593d
- gaia: 3ad2a0445acb2057db75eb107ee64288f36c0ac6

Comment 8

[Michael Vines [:m1] [:evilmachines]]

(this is a bad experience, but I don't think it's necessarily tef+ given that it only occurs when user is using camera from contacts, which is not likely to be a frequent occurrence.  if we have a low risk patch for this on v1-train then an uplift might be good to consider)

Comment 9

[Mike Habicher [:mikeh] (high bugzilla latency)]

Someone familiar with WebActivities will need probably need to take a look at this.

Comment 10

[Michael Vines [:m1] [:evilmachines]]

(bumping this to tef+ due to partner request)

Comment 11

[Mike Habicher [:mikeh] (high bugzilla latency)]

Tried the STR in comment 5 again, and this time I saw a solid b2g parent process crash (_not_ a camera app crash) when I tapped the camera icon on the lockscreen.

logcat:
E(  118:0x265) Qint android::get_camera_info(int, camera_info*): E
I(  118:0x265) Found a matching camera info for ID 0
I(  118:0x265) HAL_getCameraInfo: orientation = 90
I(  118:0x265) HAL_getCameraInfo: modes supported = 5
W(  118:0x264) CameraService::connect X (pid 107) rejected (existing client).
F(  107:0x28a) Fatal signal 11 (SIGSEGV) at 0x00000024 (code=1)
I(  110:0x6e) debuggerd committing suicide to free the zombie!
I(  651:0x28b) debuggerd: Feb 28 2013 10:55:01

The top-level problem is that the camera being invoked as a web activity is not getting the mozvisibililitychange event when the power button is tapped; but that aside, trying to open a second camera instance must not cause a crash.  I've filed a new bug 850845 to track this specific issue.

fabrice, can you help with the web activity issue?

Comment 12

[(inactive after 6/18) Alive Kuo [:alive]]

Taken to do comment 11.
It's a known issue in system app :) I hd addressed inline activity isn't getting proper visibility change in some other bug.

Comment 13

[(inactive after 6/18) Alive Kuo [:alive]]

There's another issue here:
When you have an app with inline activity opened, and you then open another app by some way(here from is lockscreen):
1. WindowManager sees open-app event.
2. WindowManager open the app(camera)
3. WindowManage remove all the current inline activities frame
4. Gecko notices the frames is terminated, send an event to tell WindowManager to open the original app
5. The origin app(contact) is opened

2.&5. is competing :/

So, I propose to close all inline activities once screen is locked.
This is the simplest way other than invent a new API for WM to tell gecko we are not invoking the activity caller app...

Comment 14

[(inactive after 6/18) Alive Kuo [:alive]]

Attachment: https://github.com/mozilla-b2g/gaia/pull/8664

Patch proposal:
Stop all inline activities while screen is locked.

Comment 15

[[:fabrice] Fabrice Desré]

What Alive proposes sounds fine to me.

Comment 16

[Mike Habicher [:mikeh] (high bugzilla latency)]

Alive, when you stop the inline process, is that the same as stopping a separate process?  (i.e. if the camera is open to add a picture to a new contact, is the camera app running in a new process?)

I'm just working out how the camera resources will be cleaned up in this case.

Comment 17

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 725240 [details]
https://github.com/mozilla-b2g/gaia/pull/8664

I thought I r+ the code already :-/

Comment 18

[(inactive after 6/18) Alive Kuo [:alive]]

https://github.com/mozilla-b2g/gaia/commit/0aa7745b3bdc1b74307d9307599a4c6d4bbacd44
master

Comment 19

[Mike Habicher [:mikeh] (high bugzilla latency)]

Please see comment 16.

Comment 20

[(inactive after 6/18) Alive Kuo [:alive]]

Sorry, I do know little about backend stuff :(

(In reply to Mike Habicher [:mikeh] from comment #16)
> Alive, when you stop the inline process, is that the same as stopping a
> separate process?  (i.e. if the camera is open to add a picture to a new
> contact, is the camera app running in a new process?)
> 
> I'm just working out how the camera resources will be cleaned up in this
> case.

Comment 21

[Mike Habicher [:mikeh] (high bugzilla latency)]

Does anyone else know?

Comment 22

[John Ford [:jhford] CET/CEST Berlin Time]

I am assuming that I shouldn't uplift this patch while this question is pending.  Please advise if I should uplift anyway.

Comment 23

[John Ford [:jhford] CET/CEST Berlin Time]

I was not able to uplift this bug to v1-train and v1.0.1.  If this bug has dependencies which are not marked in this bug, please comment on this bug.  If this bug depends on patches that aren't approved for v1-train and v1.0.1, we need to re-evaluate the approval.  Otherwise, if this is just a merge conflict, you might be able to resolve it with:

  git checkout v1-train
  git cherry-pick -x -m1 0aa7745b3bdc1b74307d9307599a4c6d4bbacd44
  <RESOLVE MERGE CONFLICTS>
  git commit
  git checkout v1.0.1
  git cherry-pick -x $(git log -n1 v1-train)

Comment 24

[(inactive after 6/18) Alive Kuo [:alive]]

I will try to uplift this one by myself.

Comment 25

[(inactive after 6/18) Alive Kuo [:alive]]

v1-train
https://github.com/mozilla-b2g/gaia/commit/f3bc9c40e1ccd6c85b0f0d1fef4715291696f99f

v1.0.1
https://github.com/mozilla-b2g/gaia/commit/ba4feb2a53d1591dcc8b6d1316fe7064340eacc1

That's not because dependency but I don't know exactly what happens when cherry-picl :/

Comment 26

[mdaniloff]

Verified Fixed in Unagi builds V.1.0.1 and V.1.1
After the user creates a new contacts page, they are able to use the camera from the locked screen


V.1.0.1
Unagi Build ID: 20130402070202
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/ccec751a468e
Gaia: ee0bef61c0a25c806dd1eec5a4e047bc418a5f73

V.1.1
Unagi Build ID: 20130402070204
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/68c8a883cfc0
Gaia: 1c38c91bb16f2bf0d5066c4787d2249463f61bb3