1018384 - [B2G][Tarako][Facebook][Camera]Performance issue attempting to exit Camera App while within Facebook with a previous photo from Gallery already added

Status: RESOLVED WONTFIX

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

Description

[Montoya Clemmons (MClemmons)]

Attachment: Firewatch Log of bug experience

User downloads and installs Facebook App from Marketplace. User taps Facebook and logs in. User taps Photo in upper middle and selects Gallery to choose an image. Once image is saved in Facebook user selects the second image placeholder and chooses Camera. If user wants to not take a picture and x out of the area, it takes significant effort (over five taps) to exit area. 

Prerequisites:
1. Download and install Facebook from Marketplace 

Repro Steps: 
1) Update a Tarako to BuildID: 20140530014002
2) Tap Facebook, then Photos
3) Tap Gallery and choose an image
4) Tap second image placeholder and choose Camera
5) Tap x

Actual: 
Device non responsive until multiple taps of the x to go back to Update Status screen.

Expected: 
Device responsive from first or second tap of x to go back to Update Status screen.

Notes: 
If user experiences Facebook closing unexpectedly during any above steps, reboot the device and try using jpeg files as uploads. jpg tend to fail often.

Repro frequency: (5/5, 100%) 

See attached: video clip = https://www.youtube.com/watch?v=J9DdwRdovro, logcat, firewatch

1.3T Environmental Variables:
Device: Tarako 1.3T
BuildID: 20140530014002
Gaia: e68858693b71d917c9c5ee7e215f7ceea04635f7
Gecko: 1945abae19ff
Version: 28.1
Firmware Version: sp6821a-gonk-4.0-5-12
User Agent: Mozilla/5.0 (Mobile; rv:28.1) Gecko/28.1 Firefox/28.1

Comment 1

[Montoya Clemmons (MClemmons)]

Attachment: Logcat Facebook Camera Issue

Comment 2

[Montoya Clemmons (MClemmons)]

This issue does not reproduce on Flame 1.4 following STR from Comment 0. Graceful transition occurs when selecting the x to leave the Camera App. 

1.4 Environmental Variables:
Device: Flame 1.4
BuildID: 20140530000202
Gaia: fe612fd21389193a8e593aa718831602e5086a62
Gecko: 25011f9a8f26
Version: 30.0
Firmware Version: v10G-2
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Comment 3

[Montoya Clemmons (MClemmons)]

This issue does not reproduce on Flame 2.0 following Comment 0 STR. Graceful transition occurs when selecting the x to leave the Camera App.


2.0 Environmental Variables:
Device: Flame 2.0
BuildID: 20140530040207
Gaia: 26d8fcab9b61f46451600f39c51e03
87ef3c4f88
Gecko: e6f113c83095
Version: 32.0a1
Firmware Version: v10G-2
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 4

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

mclemmons can you test with yesterday's build for tarako to see if you feel better or worse?

Comment 5

[Montoya Clemmons (MClemmons)]

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #4)
> mclemmons can you test with yesterday's build for tarako to see if you feel
> better or worse?

Performance is marginally better in terms of getting the camera app to exit - on Thursday's build (5/29/14), it took 3-4 taps to get the exit to occur. Unlike the 5+ for today's (5/30/14) build.

Performance is significantly worse in terms of accessing the area to select the camera and/or gallery app on Thursday's build (5/29/14). The links within the Facebook App were quite non-responsive. It took 20-25 taps to get the Gallery/Camera option to appear. Other links within the Facebook App were equally non-responsive. This behavior is not present on the 5/30/14 build. 

Below are the 5/29/14 variables

1.3T Environmental Variables:
Device: Tarako 1.3T MOZ
BuildID: 20140529014005
Gaia: 94b7ca3030b4b924f0ffe97910bb383fef9e160a
Gecko: 20ff18dbee48
Version: 28.1
Firmware Version: sp6821a-gonk-4.0-5-12
User Agent: Mozilla/5.0 (Mobile; rv:28.1) Gecko/28.1 Firefox/28.1

Comment 6

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

David, can you take a look please?  I think we have a regression based on the comments given.

Comment 7

[David Flanagan [:djf]]

Hmm. Given how incredibly sluggish the camera is when invoked from Facebook (sometimes there is a long delay after pressing the shutter button) I wonder if the X button is being tapped, but it just takes forever to process.  

Maybe all we can do is turn on the spinner while we're waiting for Facebook to come back.

Comment 8

[David Flanagan [:djf]]

Attachment: trial spinner patch

Naoki,

I don't seem to be able to reproduce this bug, but does this patch help address the issue?  All it does is display a spinner when the user clicks on the X button in the camera. So that even if the system is really slow at least there is something to look at.

If the issue is actually that something is going wrong with our touch event handling and button taps aren't being registered, then that's not something we can fix in Gaia.  But if you see a spinner show up after the first tap you know your tap was received and you just have to wait.  As I said above, though, I've seen > half second delays between touching a button (like the camera shutter) and having the tap be processed.  The system seems way overloaded in this Facebook->Camera interaction.

Comment 9

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Wouldn't adding another spinner cause more delay rather than lessen the impact?  Or is this for user feedback?

Also when I flashed the build, I didn't get a spinner after hitting x on the camera; ( to note I had to set the pref("image.mem.max_decoded_image_kb", 8000); in dev-pref.js in order to test this with facebook.

Comment 10

[Jason Smith [:jsmith]]

If we eliminate the gallery steps here, does this bug reproduce?

Comment 11

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #10)
> If we eliminate the gallery steps here, does this bug reproduce?

If that ends up being true, then I'm pretty sure this is a dupe of bug 1018485.

Comment 12

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

I agree that this may be a duplicate.  

The camera takes a long time to come up on the first attempt.
There's a spinner when the camera comes up.  During the time the spinner is occur, no touch event responds.
When cancelling with today's build it takes a long time for the cancel to occur.

With friday's build + patch, the cancel happened right away without the spinner showing.
With today's build + patch, the spinner does show and the cancel then cancels.  I'm not sure what the difference is...

Comment 13

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

I guess we should probably profile the camera coming up from facebook to see if it's an issue with facebook or with the camera call.  Should we do that here or in a separate bug?

Comment 14

[David Flanagan [:djf]]

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #9)
> Wouldn't adding another spinner cause more delay rather than lessen the
> impact?  Or is this for user feedback?
> 

The idea is to give the user some feedback that something is happening, even if displaying the spinner slightly increases the delay.  If most of the delay is occurring between the time that the user touches the X button and time time that the JavaScript callback runs, then the spinner won't do any good at all, however.


(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #13)
> I guess we should probably profile the camera coming up from facebook to see
> if it's an issue with facebook or with the camera call.  Should we do that
> here or in a separate bug?

I have not done any profiling (I'm not sure I'd know how) but have assumed that the sluggishness of the camera when invoked from Facebook is related to the zmem architecture of Tarako and memory compression or swapping or thrashing. I can't see any other reason why the camera shutter button would take a second or more to respond to a tap, for example.  (And for what its worth, the lag on the shutter button is far worse for users than the lag on the X button to dismiss!)

This seems like as good a place to investigate as any. I'm pretty sure there is nothing we can do about this in Gaia.  Maybe changes in the facebook app would help, or lower in the stack (gecko or gonk) on the Tarako, but I don't think we can do anything in the camera app other than add the spinner when we can.

Comment 15

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

ok, understood thanks.  I'll create a different bug in regards to profiling and ask the performance team to look at it.

Comment 16

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

On second thought, I will profile from open to close and place the profile in bug 1018485.  The open profile seems to cause a lot more issues.

Comment 17

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Comment on attachment 8431966 [details] [review]
trial spinner patch

I guess I will - this for now.  I didn't see as much of an issue with closing as much as I did with launching the camera.  Launching the camera ends up causing unresponsiveness to shutting down and I think that's what this bug was more about.

If I wait for the full launch of the camera and give it time, I can close out without issue.

Comment 18

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

removing qawanted, as question was answered.

Comment 19

[BMO Automation]

Firefox OS is not being worked on