933035 - [B2G][System][Lockscreen] The phone goes to sleep on the lockscreen even though screen timeout is set to never

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::System::Lockscreen, defect)

Description

[KTucker [:KTucker][Inactive 3/4/2016]]

Attachment: Screentimeout.mp4

Description:
The phone goes to sleep on the lockscreen even though screen timeout is set to never. 

Repro Steps:
1)  Updated Buri to Build ID: 20131030004003
2)  Tap on "Settings" and ensure that the "Screen lock" is enabled.
3)  Tap on "Display".
4)  Tap on the "Screen timeout" dropdown and select "never".
5)  Press the power button on the phone and turn it back on so the lockscreen is on the screen.
6)  Don't touch the screen while it is on the lockscreen.

Actual:
The phone goes to sleep even though the screen timeout is set to "never".

Expected:
The phone does not go to sleep when the screen timeout is set to "never.

Environmental Variables
Device: Buri v 1.2.0 COM RIL
Build ID: 20131030004003
Gecko: http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/4fbe1b01ed63
Gaia: a788ea1a3e04716938bd41a559c36a831cf1190b
Platform Version: 26.0a2
RIL Version: 01.01.00.019.264 

Notes:
Repro frequency: 100%
Link to failed test case: https://moztrap.mozilla.org/manage/cases/?pagenumber=1&pagesize=20&sortfield=created_on&sortdirection=desc&filter-id=9093&filter-id=9096&filter-productversion=103
See attached: video clip

Comment 1

[Greg Weng [:snowmantw][:gweng][:λ]]

In fact, this symptom happens not only on Buri. I'm now trying to pin down the root cause.

Comment 2

[John Hammink]

Not blocking, but would be helpful to find a regression range on this.

Comment 3

[Jason Smith [:jsmith]]

(In reply to John Hammink from comment #2)
> Not blocking, but would be helpful to find a regression range on this.

This isn't a regression from a past release, so there isn't value to getting a regression range at this point. We really only do regression ranges on bugs regressions that would have occurred within the past few months.

Comment 4

[Jason Smith [:jsmith]]

I'm not sure this is a regression either - this sounds like something that's existed for a while.

Comment 5

[Greg Weng [:snowmantw][:gweng][:λ]]

In fact, this is in spec: the Settings' value shouldn't affect the LockScreen timeout, at least this is what I heard from others.

And according to Alive's opinion, we can't fix this follow the existing setting path of timeout, but need to create a new way to stop the ScreenManager to make the screen timeout. I'll at least try to reset the counter while user is sliding on the LockScreen.

Comment 6

[Greg Weng [:snowmantw][:gweng][:λ]]

Mike suggest this should be solved by postpone the timeout when user is sliding. I'll follow his suggestion to send a patch.

Comment 7

[Greg Weng [:snowmantw][:gweng][:λ]]

Attachment: Patch

I added two event listeners in ScreenManager to set a unlocking flag to postpone the timeout counter when user is unlocking.

Comment 8

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

Comment on attachment 8348467 [details] [review]
Patch

r+ if there's a test case in screen manager.

Comment 9

[Greg Weng [:snowmantw][:gweng][:λ]]

Tests added and Travis was green: https://travis-ci.org/mozilla-b2g/gaia/builds/15915668
master: https://github.com/mozilla-b2g/gaia/commit/d808643fb7fca3fe6ffd1e415c135fe2d482e7df

Comment 10

[Greg Weng [:snowmantw][:gweng][:λ]]

Manually revert test was success on master, but it failed on v1.4:


master: 
https://travis-ci.org/mozilla-b2g/gaia/builds/22235055

v1.4:
https://travis-ci.org/mozilla-b2g/gaia/jobs/22235182

I need to solve the v1.4 issue. So this backout may not happen soon.

Comment 11

[Jason Smith [:jsmith]]

Can we at least backout on master in the interim?

Comment 12

[Greg Weng [:snowmantw][:gweng][:λ]]

here it is:

master: https://github.com/mozilla-b2g/gaia/commit/86ff94b32e369a925b79ae16ced141c1ac36fc0e

Comment 13

[Jason Smith [:jsmith]]

Keeping the flag "fixed" on 1.4 to indicate this is still present on 1.4.

Comment 14

[Jason Smith [:jsmith]]

Turns out the testing originally on bug 980559 wasn't right entirely - a local build with the backout didn't reproduce the bug, but this patch checked into master still reproduced the bug. Which means this isn't the cause.

So this can feel free to reland on trunk.

Comment 15

[Gregor Wagner [:gwagner]]

(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #12)
> here it is:
> 
> master:
> https://github.com/mozilla-b2g/gaia/commit/
> 86ff94b32e369a925b79ae16ced141c1ac36fc0e

Seems like a bad backout that caused bug 993281

Comment 16

[Greg Weng [:snowmantw][:gweng][:λ]]

Re-landed:

master: https://github.com/mozilla-b2g/gaia/commit/383cc27eafa461c908544dd2a3298e1b3c982a95

Comment 17

[Greg Weng [:snowmantw][:gweng][:λ]]

And Travis is green:

https://travis-ci.org/mozilla-b2g/gaia/builds/22525737

Comment 18

[Yeojin Chung [:YeojinC]]

This issue is reproduced on v.1.4 and v.2.0:

1.4F Environmental Variables:
Device: Flame 1.4F MOZ
BuildID: 20140514000204
Gaia: b40103dec34a147c9018a1af76eb21c3184f2f93
Gecko: 7788969f70b0
Version: 30.0
Firmware Version: v10F-3


2.0 Environmental Variables:
Device: Open_C 2.0 MOZ
BuildID: 20140516040203
Gaia: 7973e06dc278f67b4109ac3c33020ed086f0d042
Gecko: 58c5a3427997
Version: 32.0a1
Firmware Version: P821A10V1.0.0B06_LOG_DL

Comment 19

[Greg Weng [:snowmantw][:gweng][:λ]]

If you mean the LockScreen timeout doesn't follow the settings's timeout set, this is not a bug according to the Comment 5. It would be a bug only when you see it black out while your finger is still on the slider. Can you figure out what happen on the device?

Comment 20

[Yeojin Chung [:YeojinC]]

Thanks for the clarification. The lock screen does not black out when the user's finger is on the slider, following the timeout setting.

Comment 22

[Martijn Wargers (dead)]

(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #19)
> If you mean the LockScreen timeout doesn't follow the settings's timeout
> set, this is not a bug according to the Comment 5. It would be a bug only
> when you see it black out while your finger is still on the slider. Can you
> figure out what happen on the device?

Greg, so the screen.timeout setting doesn't work when in lockscreen mode. Is there a specific setting for toggling the lockscreen screen timeout setting. Something like lockscreen.screen.timeout or something?
I need it for some Gaia UI test to make sure that the screen stays on for longer than 10s in lockscreen mode.

Comment 23

[Martijn Wargers (dead)]

(In reply to Martijn Wargers [:mwargers] (QA) from comment #22)
> Greg, so the screen.timeout setting doesn't work when in lockscreen mode. Is
> there a specific setting for toggling the lockscreen screen timeout setting.
> Something like lockscreen.screen.timeout or something?
> I need it for some Gaia UI test to make sure that the screen stays on for
> longer than 10s in lockscreen mode.

Oh, apparently not, when I look at: http://mxr.mozilla.org/gaia/source/apps/system/js/screen_manager.js#63

Comment 24

[Greg Weng [:snowmantw][:gweng][:λ]]

I wonder first is why Gaia UI test needs that. For most manipulations they should be done within 10 seconds, since it's a long time for marionette. The only reason I could think about is the CI server is too slow (compare to real device), so we need to make the time longer. However, I don't think this is the case should be resolved by adding a test-only mozSetting value. According to UX' opinion, the time was, and is, hard-coded in code base. Of course UX didn't forcibly specify how to implement that, but my point is, if our tests are designed to match user behavior as exactly as possible, to add a test-only setting and do the test maybe isn't a good solution.

Comment 25

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

(In reply to Martijn Wargers [:mwargers] (QA) from comment #22)
> (In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #19)
> > If you mean the LockScreen timeout doesn't follow the settings's timeout
> > set, this is not a bug according to the Comment 5. It would be a bug only
> > when you see it black out while your finger is still on the slider. Can you
> > figure out what happen on the device?
> 
> Greg, so the screen.timeout setting doesn't work when in lockscreen mode. Is
> there a specific setting for toggling the lockscreen screen timeout setting.
> Something like lockscreen.screen.timeout or something?
> I need it for some Gaia UI test to make sure that the screen stays on for
> longer than 10s in lockscreen mode.

10s timeout on lockscreen is designed by UX since v1.0. Could you please elaborate more why you need to increase the timeout?

Comment 26

[Martijn Wargers (dead)]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #25)
> (In reply to Martijn Wargers [:mwargers] (QA) from comment #22)
> 10s timeout on lockscreen is designed by UX since v1.0. Could you please
> elaborate more why you need to increase the timeout?

I guess it would be something that a user wants, but probably not really important. 
http://mxr.mozilla.org/gaia/source/tests/python/gaia-ui-tests/gaiatest/apps/lockscreen/app.py#112

From automation side, this is a problem in bug 1169332.
I think I now know the cause of that. Basically, it happens when looking for elements inside the lock_screen.notifications
http://mxr.mozilla.org/gaia/source/tests/python/gaia-ui-tests/gaiatest/apps/lockscreen/app.py#112
http://mxr.mozilla.org/mozilla-central/source/testing/marionette/driver/marionette_driver/marionette.py#1581
When there are no notifications yet, this function takes 10s (see http://mxr.mozilla.org/gaia/source/tests/python/gaia-ui-tests/gaiatest/gaia_test.py#877 ), because the find_elements function will do that, until it decides there are no elements to find.
So the solution for bug 1169332 is probably to make lock_screen.notifications quicker when there are no notifications. 
But it might still be decided to disable the locskcreen screen timeout, because we do the same for regular screen.timeout.

Comment 27

[Martijn Wargers (dead)]

(In reply to Martijn Wargers [:mwargers] (QA) from comment #26)
> So the solution for bug 1169332 is probably to make
> lock_screen.notifications quicker when there are no notifications. 
> But it might still be decided to disable the locskcreen screen timeout,
> because we do the same for regular screen.timeout.

Actually, that's not a solution for that bug, because there, lock_screen.wait_for_notification is used, which should mitigate this issue. The problem here is that when a phone is waked up, then the phone call is ended, the notification is shown for 2 seconds, then the phone screen is turned black again.
So the test code has only 2 seconds (and I think even quite less) for these checks.