1075304 - [lock screen] screen lock handle won't return to its original position when passcode is turned on but not requiring passcode immediately

Status: VERIFIED FIXED

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

Description

[Kan-Ru Chen [:kanru] (UTC+9)]

Steps to reproduce:

1. Setup passcode in settings
2. Turn off screen and wait a few seconds
3. Turn on screen and entry passcode to unlock
4. Turn off screen and turn on immediately and swipe to unlock
5. Turn off screen and turn on immediately

Expected:
 The handle returned to its original position

Actual:
 The handle is still at the rightmost position

Note:
 At step 4 it doesn't require to enter the passcode to unlock, I'm not sure if it's a feature or a bug. Since in settings I choose to "Require passcode: Immediately"

Gaia-Rev        77ef35f5429bc3dfe9ca192b9aacc3c0bf8857de
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/2ae57957e4bb
Build-ID        20140930160207
Version         35.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20140925.191337
FW-Date         Thu Sep 25 19:13:47 EDT 2014
Bootloader      L1TC10011800

Comment 1

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

I think this should be solved with Tim's slide patch. Tim, this seems like your latest patch addressed, could you take a look?

Comment 2

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

I think it's a regression from my patch...

After talking to Kanru his first question on Step 4 should be a WFM because it's gone once I re-select the "Require passcode: Immediately" in his phone. However when I set my phone to "Require passcode: After 1 minute" I can definitely reproduce this bug.

Comment 3

[Mozilla Shepherd (This account is used for automation and doesn't receive bugmail)]

Attachment: mozilla-b2g:master PR#24601

Comment 4

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

Comment on attachment 8498002 [details] [review]
mozilla-b2g:master PR#24601

The state machine fail to match "passcodeTimeout: false, passcodeEnabled: true" state. This patch fix it accordingly.

Again, since we don't have a set of unit tests that go assert the specified rule (but the state functions and state manager itself), this patch contains no test :'(

Comment 5

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

As we discussed. There are much things should be done beyond this bug. Recording it here:

1. One of the root cause is State Manager should manage 'lockscreen show/hide' as a new state, that can eliminates the same state transferring issue, which now the transferring to the same state doesn't work

2. Turn events as States should be implemented

3. Unit test should test each path of state transferring, rather than just component method

4. Add transferOut method, that the State can act while the state is now leaving

These issues should come with re-factoring works so that I don't require them to be done in this bug. I would start these works ASAP, after all release blockers get resolved. I think unfortunately we still need some workarounds for the blockers similar to this issue (if any).

Comment 6

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

Comment on attachment 8498002 [details] [review]
mozilla-b2g:master PR#24601

Please review the patch again, this time includes test scripts. It turned out you *do* have test script in place to protect most of the conditions of transfer.

Comment 7

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

Comment on attachment 8498002 [details] [review]
mozilla-b2g:master PR#24601

OK I think it's good. Of course we still need some fully path-oriented unit tests in later patches, the current one only test the moment it get triggered, with the expected conditions.

Comment 8

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

https://tbpl.mozilla.org/?rev=8df55ebb666d6b1d6026bc18a89a9261767ef1d3&tree=Gaia-Try

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

Comment 9

[Adam Alldredge [:AdamA][Inactive]]

The issue is verified fixed in Flame 2.2.

Flame 2.2 Master KK (319mb) (Full Flash)

Environmental Variables:
Device: Flame 2.2 Master
BuildID: 20141012040203
Gaia: 717ad4e8b7fc10ab8248500d00ba5ba0977fa8ab
Gecko: 44168a7af20d
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Result:
The lock screen handle appeared correctly and the passcode was required immediately.

Comment 10

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

Blocking 2.2+ for all fixed regressions.