1066121 - [Flame][KK] Entering camera from lockscreen mode shows black screen

Status: RESOLVED WORKSFORME

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

Description

[No-Jun Park [:njpark]]

Attachment: cameralock.txt

STR:
Open browser, go to www.marketwatch.com.  Wait for the page to fully display
Press the top button to lock screen
Press the top button again to awake the screen.  slide to the camera

Expected:
camera shows the viewfinder
Actual: 
viewfinder is dark.

Version info:
Base Image: v180
Gaia      28d81021a6ee79b9685645eb911444212b3e2ef7
Gecko     https://hg.mozilla.org/integration/b2g-inbound/rev/ac5160346e25
BuildID   20140911051730
Version   35.0a1
ro.build.date   Thu Sep 11 08:41:26 EDT 2014
ro.bootloader   L1TC10011800
ro.build.version.incremental   eng.cltbld.20140911.084107

Comment 1

[No-Jun Park [:njpark]]

In 2.1 branch, the viewfinder shows up after around 5-6 seconds,but there is a severe lag with the updating the screen on viewfinder.

Gaia      d61264cd0c1f797b6be11e33524d8d52983c87e4
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/1d44dfce2e5b
BuildID   20140910165554
Version   34.0a2
ro.build.date   Wed Sep 10 20:15:02 EDT 2014
ro.bootloader   L1TC10011800
ro.build.version.incremental   eng.cltbld.20140910.201451

Comment 2

[Jason Smith [:jsmith]]

QA Wanted to finish off branch checks & set appropriate keywords.

Comment 3

[Cody Roesch [:croesch]]

This bug repro's on Flame KK builds Flame 2.2, Flame 2.1

Actual Results: Camera view remains black for several seconds before finally displaying the correct camera view.

Repro Rate: 4/4

Environmental Variables:
Device: Flame Master
BuildID: 20140911063332
Gaia: e3b9d0d6516177636965d97c63c60981a24a0662
Gecko: 98ea98c8191a
Version: 35.0a1 (Master) 
Firmware Version: V165
------------------------------------------------
Device: Flame 2.1
BuildID: 20140910165554
Gaia: d61264cd0c1f797b6be11e33524d8d52983c87e4
Gecko: 1d44dfce2e5b
Version: 34.0a2 (2.1)
Firmware: v165

------------------------------------------------
------------------------------------------------

This bug does NOT repro on Flame kk builds: Flame 2.0, Flame 1.4 (base) and OpenC 2.2

Actual Result: When checking the camera from the lockscreen after viewing www.marketwatch.com, there is no noticiable problems with long loading times before the camera view appears.

Repro Rate: 0/3 attempts

Environmental Variables:
Device: Flame 2.0
BuildID: 20140910161756
Gaia: ddec117b2d6ac8ea50d7fd833a9cf0605d5b358b
Gecko: 271294ee1e5a
Version: 32.0 (2.0) 
Firmware Version: v165
---------------------------------------------------
Device: Flame 1.4 (base)
BuildID: 20140814202332
Gaia: 129211661489feb60bbd6772a44081d23b374f17
Gecko: 
Version: 30.0 (1.4)
Firmware: v165
---------------------------------------------------
Environmental Variables:
Device: Open_C Master
BuildID: 20140911063332
Gaia: e3b9d0d6516177636965d97c63c60981a24a0662
Gecko: 98ea98c8191a
Version: 35.0a1 (Master) 
Firmware Version: P821A10V1.0.0B06_LOG_DL

Comment 4

[Joshua Mitchell (Inactive)]

[Blocking Requested - why for this release]: regression in a major feature / bad UX - to users, the reason to have camera accessible from the lockscreen is to be able to quickly take a picture, lag or black screens would be VERY frustrating.

Comment 5

[Hema Koka [:hema]]

Blocking Reason: comment 4

Comment 6

[David Flanagan [:djf]]

How much memory on the Flame? If this is a low-mem 319mb device, this may simply be ordinary swapping/thrashing caused by running the browser, the lockscreen and the camera all at once.

Also: is there something special about the marketwatch.com website? Or does it happen with any site? It would be interesting to know how much mem the browser requires to use that site. And it would be interesting to know if that site is dynamically sending stock market updates to the phone in the background, since that might affect memory usage and cpu activity.

Comment 7

[David Flanagan [:djf]]

How does the lockscreen launch the camera these days? Does it do it the same way the homescreen does, or does it use the activity that Gallery uses to launch camera?  Justin: could there be any relevant difference in the startup path in those two cases?  Just guessing here.

Comment 8

[No-Jun Park [:njpark]]

(In reply to David Flanagan [:djf] from comment #6)
> How much memory on the Flame? If this is a low-mem 319mb device, this may
> simply be ordinary swapping/thrashing caused by running the browser, the
> lockscreen and the camera all at once.
> 
> Also: is there something special about the marketwatch.com website? Or does
> it happen with any site? It would be interesting to know how much mem the
> browser requires to use that site. And it would be interesting to know if
> that site is dynamically sending stock market updates to the phone in the
> background, since that might affect memory usage and cpu activity.

Yes it was found in 319mb Flame device.
As far as marketwatch.com, it does have a lot of content to render, so I assume it will consume more memory than handling simpler sites.  This site seems to give memory pressure to the device, so we use it often to see how the device handles.  From what I see, it does look like the lag is caused by lack of memory as well.  Not sure what's the expected behavior when the device is low on memory and something like this happens- in tarako, I believe background apps were killed to make room, but in this case the device is forced to handle 3 apps at once.

Comment 9

[Justin D'Arcangelo [:justindarc]]

(In reply to No-Jun Park [:njpark] from comment #0)
> Created attachment 8487964 [details]
> cameralock.txt
> 
> STR:
> Open browser, go to www.marketwatch.com.  Wait for the page to fully display
> Press the top button to lock screen
> Press the top button again to awake the screen.  slide to the camera
> 
> Expected:
> camera shows the viewfinder
> Actual: 
> viewfinder is dark.
> 
> Version info:
> Base Image: v180
> Gaia      28d81021a6ee79b9685645eb911444212b3e2ef7
> Gecko     https://hg.mozilla.org/integration/b2g-inbound/rev/ac5160346e25
> BuildID   20140911051730
> Version   35.0a1
> ro.build.date   Thu Sep 11 08:41:26 EDT 2014
> ro.bootloader   L1TC10011800
> ro.build.version.incremental   eng.cltbld.20140911.084107

Where can I get base image v180? The latest base image I have for KK is v166.

Comment 10

[No-Jun Park [:njpark]]

(In reply to Justin D'Arcangelo [:justindarc] from comment #9)
> (In reply to No-Jun Park [:njpark] from comment #0)
> > Created attachment 8487964 [details]
> > cameralock.txt
> > 
> > STR:
> > Open browser, go to www.marketwatch.com.  Wait for the page to fully display
> > Press the top button to lock screen
> > Press the top button again to awake the screen.  slide to the camera
> > 
> > Expected:
> > camera shows the viewfinder
> > Actual: 
> > viewfinder is dark.
> > 
> > Version info:
> > Base Image: v180
> > Gaia      28d81021a6ee79b9685645eb911444212b3e2ef7
> > Gecko     https://hg.mozilla.org/integration/b2g-inbound/rev/ac5160346e25
> > BuildID   20140911051730
> > Version   35.0a1
> > ro.build.date   Thu Sep 11 08:41:26 EDT 2014
> > ro.bootloader   L1TC10011800
> > ro.build.version.incremental   eng.cltbld.20140911.084107
> 
> Where can I get base image v180? The latest base image I have for KK is v166.

Hi Justin, I forwarded you the email.  I got the email yesterday from the Taiwan team.

Comment 11

[Chris Kreinbring [:CKreinbring]]

The bug repros on the earliest build we have available with 319 MB memory.

BuildID: 20140417000006
Gaia: 7591e9dc782ac2e97d63a96f9deb71c7b3588328
Gecko: e71ed4135461
Platform Version: 31.0a1
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:31.0) Gecko/31.0 Firefox/31.0

Comment 12

[Joshua Mitchell (Inactive)]

Just to add some clarity - The above 'regression window' was done on JB builds (because we only have a handful of KK builds built up - not enough for all but the most recent of regressions) - In JB the bug does repro in earlier branches marked unaffected in KK - so please don't be confused / concerned with the above post. 

Actual Results - a delay of 5-6 seconds occurred when sliding lockscreen to camera

Comment 13

[Justin D'Arcangelo [:justindarc]]

Following the STR in Comment 0, I'm unable to reproduce using Flame-KK base image v180 with a 319mb memory configuration. I am, however, seeing the 5-6 second delay in loading Camera (viewfinder shows the spinner while it loads).

Comment 14

[Justin D'Arcangelo [:justindarc]]

I just re-tested this using latest master (v2.2) on Flame 319mb (KK-v180) as well as latest v2.1 and master (v2.2) branches on Flame 319mb (JB-v123) and was unable to reproduce in any of them. I do see a longer delay than normal in starting up the Camera viewfinder, but the Camera app still always manages to launch properly from the lockscreen (following STR from Comment 0).

Flagging :njpark for info to see if this is still an issue.

Comment 15

[No-Jun Park [:njpark]]

I tested in latest master on Flame 319mb (KK-v180).  I noticed that if there is no background apps running, the switch to camera app was responsive, but if I was on a complex browser webpage (ex. marketwatch.com), locked the phone, and then swiped to camera, it took a while for me to see the viewfinder.  Similiarly, if I had multiple background apps (settings, gallery, contacts) the effect was same.  It took a while to switch to the app, then it took extra 3~4 seconds for the viewfinder to display.

I guess the question is if there are a number of background apps running, is it acceptable to have the low response time for the switch to the camera app?  Or should everything run at the same speed, regardless of how many apps I have running on the background?

Comment 16

[Justin D'Arcangelo [:justindarc]]

(In reply to No-Jun Park [:njpark] from comment #15)
> I tested in latest master on Flame 319mb (KK-v180).  I noticed that if there
> is no background apps running, the switch to camera app was responsive, but
> if I was on a complex browser webpage (ex. marketwatch.com), locked the
> phone, and then swiped to camera, it took a while for me to see the
> viewfinder.  Similiarly, if I had multiple background apps (settings,
> gallery, contacts) the effect was same.  It took a while to switch to the
> app, then it took extra 3~4 seconds for the viewfinder to display.
> 
> I guess the question is if there are a number of background apps running, is
> it acceptable to have the low response time for the switch to the camera
> app?  Or should everything run at the same speed, regardless of how many
> apps I have running on the background?

Based on the fact that this bug (as described in Comment 0) is no longer reproducible, I'm going to close this as WORKSFORME. If we want to address the response time of switching apps under heavy load on 319mb, we should track that in a separate bug.