1182342 - lock screen active based on time it last appeared and not time since last activity

Status: RESOLVED WONTFIX

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

Description

[Jean-Yves Avenard [:jya]]

User-Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

I have the lock screen set to be active after one minute.

This time appears to be the amount of time since the last lock screen was shown rather the amount of inactivity time. 

The lock settings page doesn't say anything about what that time means, but almost any device I use: being iPhone, android or desktop implies that this is the amount of inactivity. 

If I've been using the phone for over a minute, press the off button to turn it off and again to turn it on, then you're immediately prompted for your pin. 

One would expect that as the amount of inactivity time is less than a minute: you won't be prompted for the pin. 

If this is the expected behaviour that's fine, but I believe this should be described in the settings page as the behaviour is different to anything out there. 

Also, one important problem stemming from this behaviour is that if you're in a call, the screen turns off and the next time the screen turns on (either by.moving the phone away from your ear or pressing the power button) you get prompted for your PIN.

Comment 1

[Lance（leave from Mozilla）]

The bug can be reproduced on latest build of Flame master and Aires 2.5, but can not be reproduced on latest Flame 2.2.

Fail rate:
5/5(Flame master/Aires 2.5), 0/5 (Flame 2.2)

Found time:16:04
See attachments:Flame_2.5.3gp and logcat_1604.txt

Steps:
1.Launch Settings.
2.Tap "Screen Lock", then set the passcode.
3.Change the "Require passcode" to "After 1 minute".
4.Press power key to lock screen, then unlock screen.
5.Perform some operations for more than 1 minute.
6.Press power key again, then unlock screen.

Actual result:
Step 6.Flame master and Aires 2.5: Device will enter input passcode page.
Step 6.Flame 2.2: Device will enter Home page.

Note: If you're in a call, the screen turns off and the next time the screen turns on (either by.moving the phone away from your ear or pressing the power button), Flame master and Aires 2.5 will enter the lock screen page. When screen turns off more than 1 minute, Flame 2.2 will enter the lock screen page.

Device: Aries KK 2.5(Affected)
Build ID               20150723024716
Gaia Revision          f04fdbfa1943dddeab8ecd1299a76ab56e590d00
Gaia Date              2015-07-22 18:44:09
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/2ddec2dedced
Gecko Version          42.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20150723.023231
Firmware Date          Thu Jul 23 02:32:39 UTC 2015
Bootloader             s1

Device: Flame KK 2.5(Affected)
Build ID               20150727150208
Gaia Revision          14e32276025b0310d3e89027320cf4b2a24cedfb
Gaia Date              2015-07-27 16:43:18
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/c0a3d6f72a63
Gecko Version          42.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150727.183206
Firmware Date          Mon Jul 27 18:32:18 EDT 2015
Firmware Version       v18D v4
Bootloader             L1TC000118D0

Device: Flame KK 2.2(Unffected)
Build ID               20150727152503
Gaia Revision          e1e6317f17a840b19af9dbb25f5a771d8d9fa161
Gaia Date              2015-07-15 21:05:11
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/9d103025178f
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150727.184844
Firmware Date          Mon Jul 27 18:48:55 EDT 2015
Firmware Version       v18D v4
Bootloader             L1TC000118D0

Comment 2

[Lance（leave from Mozilla）]

Attachment: logcat_1604.txt

Comment 3

[Lance（leave from Mozilla）]

Attachment: Flame_2.5.3GP

Comment 4

[Gerry Chang [:gchang]]

Hi Fred, 
Can you help to dispatch this to right owner?

Comment 5

[[e-mail]]

Since 2.2 is Unffected, set regressionwindow-wanted to find out when the regression occurred

Comment 6

[[e-mail]]

[Blocking Requested - why for this release]: regression

Comment 7

[Mahendra Potharaju [:mahe]]

Broken functionality. Blocking for 2.5.

Comment 8

[Christiane Ruetten [INACTIVE]]

Greg, I think you need to look into this.

Comment 9

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

In fact I suspect in v2.2 we have some bugs, if it really works as Comment 1 and video. Since to listen what user is doing after screen locker has not been implemented intentionally, or at least not implemted by me and not in screen locker (maybe window manager did that). So I rather to wait regression window first.

Comment 10

[Michael Bryant (uber)]

Initial Regression Window: Mozilla-central-flame

Last Working

Device: Flame
Build ID: 20150224010314
Gaia: 31ac1cd7a029d5e46dd7c92537b5c973c5d9826e
Gecko: 368c62292249
Version: 39.0a1
Firmware Version: v18d

First Broken

Device: Flame
Build ID: 20150224160313
Gaia: f6bfd854fe4746f21bc006eac145365e85f98808
Gecko: 0a8b3b67715a
Version: 39.0a2
Firmware Version: v18d

Last Working Gaia, First Broken Gecko - Doesn’t reproduce
Gaia: 31ac1cd7a029d5e46dd7c92537b5c973c5d9826e
Gecko: 0a8b3b67715a

First Broken Gaia, Last Working Gecko - Does reproduce
Gaia: f6bfd854fe4746f21bc006eac145365e85f98808
Gecko: 368c62292249

B2G Inbound Pushlog (Gaia)
https://github.com/mozilla-b2g/gaia/compare/31ac1cd7a029d5e46dd7c92537b5c973c5d9826e...f6bfd854fe4746f21bc006eac145365e85f98808

Comment 11

[[e-mail]]

might related to in Bug 1115311 (land clock widget)

Comment 12

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

I will try to do a bisect according to the regression window and fix that. Keep NI in my queue.

Comment 13

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

I've done some investigations and found something:

1. On the latest v2.2 build it is actually BROKEN, if STR0 is what we want: after unlocking it, no matter whether you let your device idle or not, it will NOT require the passcode after the 1 min, while STR0 asks to require that ONLY when you let your device idle (away from the fingers) more than 1 min. But it will ask you the passcode after the screen is off longer than one minute, which is aligned with the behavior on the master build.

2. On master it is as what we always expected: it will require the passcode after 1 min unlocking or locking time. And the "idle" time will not affect that.

3. The most important thing is I've double checked the code: we actually DON'T check whether the device is idle or not: the timeout of requesting passcode is only affected by unlocking and locking time, and on master this part is exactly the same with v2.2. I've also searched the System files, no one looks providing such event to notify whether the user is active or not. Moreover, even ScreenManager, which may be considered to control the screen off while it is idle, does not receive any event (a conclusion from WebIDE with breakpoint) when the device screen dimmed due to the inactivity.

Therefore, I believe this is NOT a regression, since on v2.2 and master they behavior as the same, and the code also remain the same. this bug can only be a feature request, which:

1. Needs something new to detect if user is touching anywhere in any frame after unlocking it, since user may touch app or Homescree or even System app itself, if the finger is on the utility tray or something like that.

2. Needs UX to confirm the new spec with a formal diagram as other features

3. Needs to be triaged again: since it does not a regression as Comment 6, and only blocks a function that never exists since v2.2 as I tested, which was the reason to make it as blocker at Comment 7. So either we admit it's a very late feature and push it into the v2.5 *with lots of risks* (since the technique difficulties of 1. are not easy to solve), or we unblock that and mark it as a new feature for maybe v3.0.

4. From the code and the regression window issue (listed below), I don't think it's the issue from Bug 1115311.

NI Tim since this should be re-triaged, remove the regression flags that QA and others though it is, and we may need to discuss how to deal with the request.

---
About the regression window: the "broken" window as QA tested actually included the period the timeout function was broken: which means no matter whether you set the timeout or not, it will ALWAYS ask the passcode. That, plus the result of my test on v2.2, means the window has some outside factors in the "broken" symptom, and makes me don't think it's regression at all.

Comment 14

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

Agreed this is a request for behavior change rather than a regression.

That said, we should still try to plan on it for future versions.

Comment 15

[BMO Automation]

Firefox OS is not being worked on