Greg Weng [:snowmantw][:gweng][:λ] Assignee
	Description • 10 years ago

Description:
Locking the device right after entering a passcode leaves the user in an unexpected state (black screen). 

Prerequisite: Enable lockscreen and a Passcode in settings. 

Repro Steps:
1)  Lock the device.
2)  Slide to unlock the lock screen.
3)  Enter a passcode and immediately lock the device.
4)  Wake the device up and notice the lockscreen.

Actual:
The screen after unlocking would become an black window.

Expected:
The user can unlock their device without issue.

	Greg Weng [:snowmantw][:gweng][:λ] Assignee
	Comment 1 • 10 years ago

[Blocking Requested - why for this release]: This is a bug from the 2.1 blocker Bug 1064630. As we discussed in that bug, the different symptoms and code should be different bug. So I fire this one.

	howie [:howie]
	Comment 2 • 10 years ago

Triage: regression, blocking.

	KTucker [:KTucker][Inactive 3/4/2016]
	Comment 3 • 10 years ago

Adding qawanted for branch checks.

	Adam Alldredge [:AdamA][Inactive]
	Comment 4 • 10 years ago

This issue occurs in 2.0 Flame and 2.0 Flame (Base)

Environmental Variables:
Device: Flame 2.0 (Shallow Flash)
BuildID: 20141001060124
Gaia: 8079cba2133e6f5443dba24dad077f7f91e6c978
Gecko: 66c1ea78b6c1
Version: 32.0 (2.0)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Device: Flame 2.0
BuildID: 20140904160718 (Base)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Result:
Phone enters unresponsive state.

----------------------------------------------------
This issue does not occur in 2.2 Flame or 2.1 Flame.

Environmental Variables:
Device: Flame 2.2 Master (Shallow Flash)
BuildID: 20141001060621
Gaia: a23d2c490b39c4699c9375e25c4acdf396a2fa85
Gecko: 835ef55e175e
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Device: Flame 2.1 (Shallow Flash)
BuildID: 20141001105624
Gaia: c1cc61e30f5cb3446f1692ff9fd1e32232f6a231
Gecko: 3b859b93de23
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Result:
Phone returns to lock screen

	Greg Weng [:snowmantw][:gweng][:λ] Assignee
	Comment 5 • 10 years ago

I found this is *irrelevant* to passcode. If you unlocking without passcode and press power button at the specific moment, it still occurs. And I think it's not fully failed at LockScreen but AWM. So I would change the title and try to pin down the root cause.

	Greg Weng [:snowmantw][:gweng][:λ] Assignee
	Comment 6 • 10 years ago

Alive: I've found the possible root cause is when the unlocking animation is performing, user turn off and on the screen quickly, and there seems two defects lead to the bug:

1. lockscreen.js would wait nextPaint and then fire the 'will-unlock' event to close the lockscreen app, after user slide or typing passcode to activate unlocking. But if user turn off and then turn on the screen in this waiting moment, it means we shouldn't fire the event to unlock, since to turn on the screen before unlocking is done means the device should be locked.

2. When the unlocking animation is performing and the screenchange event comes twice, the old path would make LWM try to open the app twice. But since the LW  now is closing itself, the LW can't open it again during this closing time. Thus, after the moment passed, we get a *not opened* LockScreenWindow (although it ought to be opened), and the background app is inactive, which is correct but visually cause the symptom.

To fix this, I now close the LW immediately while the screen is off, and then when the screen is on again, the LW can be opened as expected. I test the patch manually on my Flame, and the bug seems fixed with my patch.

I don't know whether master and v2.1 has this or not, but if it's necessary I would land it on these two branches as well, unless this is actual a 2.0 only bug.

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 7 • 10 years ago

Comment on attachment 8499991 [details]
Patch v2.0

r+ with nit

	Greg Weng [:snowmantw][:gweng][:λ] Assignee
	Comment 8 • 10 years ago

Comment on attachment 8499991 [details]
Patch v2.0

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): The event handling and the state changing has bug, so I change the way to handling them.
[User impact] if declined: LockScreen still broken while unlocking
[Testing completed]: Gaia-Try failed with only intermittent errors. I now re-run it.
[Risk to taking this patch] (and alternatives if risky): No obvious possible issues
[String changes made]: No

I don't know whether this is serious enough but since it's 2.0+, so I submit the approval request.

	bhavana bajaj [:bajaj]
	Comment 9 • 10 years ago

(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #8)
> Comment on attachment 8499991 [details]
> Patch v2.0
> 
> [Approval Request Comment]
> [Bug caused by] (feature/regressing bug #): The event handling and the state
> changing has bug, so I change the way to handling them.
> [User impact] if declined: LockScreen still broken while unlocking
> [Testing completed]: Gaia-Try failed with only intermittent errors. I now
> re-run it.
> [Risk to taking this patch] (and alternatives if risky): No obvious possible
> issues
> [String changes made]: No
> 
> I don't know whether this is serious enough but since it's 2.0+, so I submit
> the approval request.

Can you please post the try run result here?

	Greg Weng [:snowmantw][:gweng][:λ] Assignee
	Comment 10 • 10 years ago

The test now is green perfectly on Gaia-Try:

https://treeherder.mozilla.org/ui/#/jobs?repo=gaia-try&revision=8d8e2c213e92

	bhavana bajaj [:bajaj]
	Comment 11 • 10 years ago

(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #10)
> The test now is green perfectly on Gaia-Try:
> 
> https://treeherder.mozilla.org/ui/#/jobs?repo=gaia-try&revision=8d8e2c213e92

Thanks!

	Greg Weng [:snowmantw][:gweng][:λ] Assignee
	Comment 12 • 10 years ago

v2.0: https://github.com/mozilla-b2g/gaia/commit/2183b4f3ec0eb47ab1f133c31732ec53b08ad253

	Kai-Zhen Li [:seinlin][:kli]
	Comment 13 • 10 years ago

v2.0m: https://github.com/mozilla-b2g/gaia/commit/2183b4f3ec0eb47ab1f133c31732ec53b08ad253

	Yeojin Chung [:YeojinC]
	Comment 14 • 10 years ago

This issue is verified fixed on Flame 2.0.

Result: The lockscreen appears properly.

Device: Flame 2.0 (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141031000201
Gaia: 7b8df9941700c1f6d6d51ff464f0c8ae32008cd2
Gecko: 82a6ed695964
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 32.0 (2.0) 
Firmware Version: v188
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

	Coler
	Comment 15 • 10 years ago

Verify passed, this issue can't be repro on Woodduck 2.0.
Attached: Verify_Woodduck_LockScreen.mp4
Reproducing rate: 0/5
Gaia-Rev        ee5cf148b4c546beea9bfb799d2a3ee62074957d
Gecko-Rev       73601b71861cbc2f180c4d2653cec3e9fbb39db5
Build-ID        20141114050313
Version         32.0