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.
QA Whiteboard: [foxfood-triage]
Component: Gaia::Feedback → Gaia::System::Lockscreen
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
QA Whiteboard: [foxfood-triage] → [foxfood-triage][MGSEI-Triage+]
status-b2g-v2.2: --- → unaffected
status-b2g-master: --- → affected
Hi Fred, Can you help to dispatch this to right owner?
Since 2.2 is Unffected, set regressionwindow-wanted to find out when the regression occurred
[Blocking Requested - why for this release]: regression
blocking-b2g: --- → 2.5?
Broken functionality. Blocking for 2.5.
blocking-b2g: 2.5? → 2.5+
Greg, I think you need to look into this.
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.
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
might related to in Bug 1115311 (land clock widget)
I will try to do a bisect according to the regression window and fix that. Keep NI in my queue.
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.
Flags: needinfo?(gweng) → needinfo?(timdream)
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.
blocking-b2g: 2.5+ → ---
feature-b2g: --- → 3.0?
status-b2g-v2.2: unaffected → ---
status-b2g-master: affected → ---
Keywords: regression, regressionwindow-wanted → feature
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.