"Add Picture" from Camera doesn't exit activity if Camera app is already running

RESOLVED DUPLICATE of bug 818933

Status

Firefox OS
Gaia::Camera
P2
normal
RESOLVED DUPLICATE of bug 818933
5 years ago
5 years ago

People

(Reporter: cjones, Unassigned)

Tracking

unspecified
B2G C3 (12dec-1jan)
x86_64
Linux
Dependency tree / graph

Firefox Tracking Flags

(blocking-basecamp:+)

Details

(Whiteboard: [fix in bug 818933])

STR
 (1) Add new contact
 (2) Tap "Add Picture"
 (3) Choose camera activity
 (4) Take snapshot

Sometimes this works and sometimes not.  When it doesn't work, the camera happily snaps an image and stays open.  No image is returned to the contacts app and we're "stuck" in the activity.
Reliable STR
 (1) Launch Camera app
 (2) Add new contact
 (3) Tap "Add Picture"
 (4) Choose camera activity
 (5) Take snapshot

The image strip shows up and we stay in the camera.
Keywords: qawanted
Summary: "Add Picture" from Camera intermittently fails to exit activity → "Add Picture" from Camera doesn't exit activity if Camera app is already running

Updated

5 years ago
Component: Gaia → Gaia::Camera
QA Contact: jhammink
Minusing until it is reprodeced.
blocking-basecamp: ? → -
Keywords: qawanted
Comment #1 says reproducible -> blocking.
blocking-basecamp: - → +

Comment 4

5 years ago
Hi Chris - this one is marked qawanted, but what do you need us to do?  Just try to repro?

In any case, it works correctly on 12/3/ (stable) - that is, control is returned back to contact I'm creating after photo snapped, so resolving=>wfm, and removing qawanted.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Flags: needinfo?(jones.chris.g)
Keywords: qawanted
Resolution: --- → WORKSFORME
This is still broken in the latest gaia/gecko.

Please follow the steps in comment 1.
Status: RESOLVED → REOPENED
Flags: needinfo?(jones.chris.g)
Resolution: WORKSFORME → ---
Can we get a priority and target milestone for this>
Priority: -- → P2
Target Milestone: --- → B2G C3 (12dec-1jan)
Assignee: nobody → yurenju
So I followed the STR in comment 1 and I don't see the same issue.

For me, the activity closes as expected but the "Add picture" sections remains empty as if nothing was returned from the activity.
Assignee: yurenju → nobody
Accroding comment 1, I can reproduce this issue. 

After investigated today, There are two instances: inline activity and running camera app. This issue looks like _pendingPick assigned in inline activity, but click event of captureButton is handled by running app.
Assignee: nobody → yurenju
Tim will help me on this issue.
Assignee: yurenju → timdream+bugs
OK, there are two problems here.

We'll always open another inline frame for the inline activity, if the inline frame comes with the same URL of the app frame and the app is running, activity system message will often being routed to the wrong frame. This can be workarounded/fixed by switching the activity URL to something like ?inline. I am not sure if there is a platform bug filed yet.

Another bug regarding camera is kind of related to bug 818955, where two frames is trying to grab the same camera hardware. We could workaround the issue by having the Camera app to release(?) the camera when it is being put to background, instead of pause() the stream. Should I do that?
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #10)
> Another bug regarding camera is kind of related to bug 818955, where two
> frames is trying to grab the same camera hardware. We could workaround the
> issue by having the Camera app to release(?) the camera when it is being put
> to background, instead of pause() the stream. Should I do that?

According to Chiajung at bug 818955 comment 11, "release" the camera is not possible. He is still trying; I will hold off the fix on this.

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #10)
> We'll always open another inline frame for the inline activity, if the
> inline frame comes with the same URL of the app frame and the app is
> running, activity system message will often being routed to the wrong frame.
> This can be workarounded/fixed by switching the activity URL to something
> like ?inline. I am not sure if there is a platform bug filed yet.

I can at least fix this on Camera app, or WindowManager if it turns out to be simple.
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #11)
> (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #10)
> > Another bug regarding camera is kind of related to bug 818955, where two
> > frames is trying to grab the same camera hardware. We could workaround the
> > issue by having the Camera app to release(?) the camera when it is being put
> > to background, instead of pause() the stream. Should I do that?
> 
> According to Chiajung at bug 818955 comment 11, "release" the camera is not
> possible. He is still trying; I will hold off the fix on this.

This part is now depend on bug 818933.
Depends on: 818933
I can confirm that the camera issue is the same as what's observed in bug 818933, and that the patch pending there fixes it.
Whiteboard: [fix in bug 818933]
dietrich, et al: just to be clear, bug 818933 only fixes _one_ of the issues mentioned in this bug.  I can also reproduce the problem where tapping on "Add Picture" in a new contact starts the camera, but taking a picture doesn't return you to the contact.  That is _not_ fixed by 818933.
The other issue is fixed (I think) in the patch attached to #819200
(In reply to David Flanagan [:djf] from comment #15)
> The other issue is fixed (I think) in the patch attached to #819200

Yes, https://github.com/mozilla-b2g/gaia/pull/7023/files#L2R33 !

Looks like there is nothing to fix in this bug after two of the fixes lands....
Depends on: 819200
Duplicate of this bug: 820810
I am going to dup this one to bug 818933 just to make the statistics clean :)
Assignee: timdream+bugs → nobody
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 818933
You need to log in before you can comment on or make changes to this bug.