Closed Bug 1139540 Opened 9 years ago Closed 9 years ago

[Privacy Panel][Remote Lock] Lockscreen becomes unresponsive after remote lock

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.5+, b2g-v2.2 unaffected, b2g-master fixed)

VERIFIED FIXED
2.2 S8 (20mar)
blocking-b2g 2.5+
Tracking Status
b2g-v2.2 --- unaffected
b2g-master --- fixed

People

(Reporter: ychung, Assigned: gweng)

References

()

Details

(Keywords: privacy, regression)

Attachments

(2 files)

Description:
When the device receives the remote lock command via SMS, the device locks properly. However, the lockscreen becomes unresponsive, and the user is unable to unlock the device, until pressing the power button twice.

Repro Steps:
1) Update a Flame to 20150304062601.
2) Navigate to Settings > Privacy Panel.
3) After going through the tutorial pages, select "Remote Protection".
4)) Set up with a passphrase.
5) Enable "Remote Lock".
6) From another device, send 'RP lock <PASSPHRASE>' in an SMS to the DUT.
7) Observe the device is locked. Try to unlock the device.

Actual:
The lockscreen is unresponsive. The user has to press the power button twice to unlock the device.

Expected:
The lockscreen is responsive.

Environmental Variables:
Device: Flame 3.0 (KK, 319mb, shallow flash)
Build ID: 20150304062601
Gaia: b64104b4e92b9f41d71f8e85c6c22344d6479a06
Gecko: a27dd304348d
Version: 39.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0

Repro frequency: 10/10
See attached: video clip, logcat
http://youtu.be/pTFKY1D1guo
This issue does NOT reproduce on Flame 2.2.

Result: The lockscreen works properly after getting locked by remote lock.

Environmental Variables:
Device: Flame 2.2 (KK, 319mb, shallow flash)
BuildID: 20150303131648
Gaia: 8b4b3e4b7e7c308764f71542437fd60625ac6b75
Gecko: 2cb52b7cda5a
Version: 37.0 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
QA Whiteboard: [QAnalyst-Triage?][COM=Privacy Panel]
Flags: needinfo?(ktucker)
[Blocking Requested - why for this release]:

Nominating this 3.0? since this is a regression and the user will not be able to unlock their device.
blocking-b2g: --- → 3.0?
QA Whiteboard: [QAnalyst-Triage?][COM=Privacy Panel] → [QAnalyst-Triage+][COM=Privacy Panel]
Component: Gaia → Gaia::System::Lockscreen
Flags: needinfo?(ktucker)
Assignee: nobody → ychung
Assignee: ychung → nobody
QA Contact: ychung
b2g-inbound Regression Window:

Last Working Environmental Variables:
Device: Flame 3.0
BuildID: 20150223221520
Gaia: 6ac2493449e49622af77c12b4b602cb9c01a66ed
Gecko: 395b88463487
Version: 39.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0

First Broken Environmental Variables:
Device: Flame 3.0
BuildID: 20150223225323
Gaia: 123e7e33965c5bfca3238913f2b2828fe77eee9e
Gecko: e75a3c76835a
Version: 39.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0

Last Working Gaia First Broken Gecko: Issue does NOT reproduce 
Gaia: 6ac2493449e49622af77c12b4b602cb9c01a66ed
Gecko: e75a3c76835a

First Broken Gaia Last Working Gecko: Issue DOES reproduce
Gaia: 123e7e33965c5bfca3238913f2b2828fe77eee9e
Gecko: 395b88463487

https://github.com/mozilla-b2g/gaia/compare/6ac2493449e49622af77c12b4b602cb9c01a66ed...123e7e33965c5bfca3238913f2b2828fe77eee9e

Possibly caused by bug 1115311
QA Whiteboard: [QAnalyst-Triage+][COM=Privacy Panel] → [QAnalyst-Triage?][COM=Privacy Panel]
Flags: needinfo?(ktucker)
QA Contact: ychung
Greg, can you take a look at this please? Looks like the landing for Bug 1115311 might have caused this to occur.
QA Whiteboard: [QAnalyst-Triage?][COM=Privacy Panel] → [QAnalyst-Triage+][COM=Privacy Panel]
Flags: needinfo?(ktucker) → needinfo?(gweng)
OK I've successfully reproduced it programmatically with such code in WebIDE:

var settings = {
        'lockscreen.enabled': true,
        'lockscreen.notifications-preview.enabled': false,
        'lockscreen.passcode-lock.enabled': true,
        'lockscreen.lock-immediately': true
};
var request = SettingsListener.getSettingsLock().set(settings);

This is the simplified code from FindMyDevice app, and the symptom is the same.
Let's see what nasty thing happens when the instructions got sent.
Flags: needinfo?(gweng)
I've found if 'lockscreen.lock-immediately' fired after 'lockscreen.enabled', as the normal sequence user would follow, the bug disappeared.
Hmm...the way I've mentioned at Comment 5 is invalid now. Need to find new programmatic way to debug this.
I've found that I can't reproduce this bug with the current master. I've flashed my Flame from the pvt build ('./flash_pvt.py' and then choose flame-kk, Gecko + Gaia), and set the remote protection. The video:

https://www.youtube.com/watch?v=4NRcIhbBFKQ&feature=youtu.be

After the SMS from another device got sent, there are two issues:

1. The receiver one would take very long time to lock it. In the video you can see I can even click the message and then to scroll the Homescreen down, then the LockScreen appears

2. After the LockScreen appeared, the slider & unlocking works well. There is no issue like the video of the original STR shows.

I don't know whether I did it wrong or not, but I've tried this 3 times and it never works (never failed).

----
My Flame:

Gaia-Rev        0017f2bbc63781a5409644b664d80ebaa1543653
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/56492f7244a9
Build-ID        20150304160447
Version         39.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150301.172220
FW-Date         Sun Mar  1 17:22:31 EST 2015
Bootloader      L1TC000118D0
Flags: needinfo?(ktucker)
Adding qawanted in regards to Comment 8.
Flags: needinfo?(ktucker)
Keywords: qawanted
QA Contact: ychung
I tried it again on the latest Flame Master. The issue did not reproduce on the very first time, but reproduced afterwards. Here's my video that shows the first and the second attempts:

http://youtu.be/QF49chea3zI

Environmental Variables:
Device: Flame 3.0
BuildID: 20150305071903
Gaia: 0017f2bbc63781a5409644b664d80ebaa1543653
Gecko: 993eb76a8bd6
Version: 39.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0
QA Whiteboard: [QAnalyst-Triage+][COM=Privacy Panel] → [QAnalyst-Triage?][COM=Privacy Panel]
Flags: needinfo?(ktucker)
Keywords: qawanted
QA Contact: ychung
QA Whiteboard: [QAnalyst-Triage?][COM=Privacy Panel] → [QAnalyst-Triage+][COM=Privacy Panel]
Flags: needinfo?(ktucker)
Triage: blocking. Greg will help to take a look if this is lockscreen issue. If not, we need privacy panel dev's help.
blocking-b2g: 3.0? → 3.0+
Flags: needinfo?(gweng)
I've found when the bug occurs, the whole System is very laggy even after I unlock it. I suspect that there are some more nasty things happen outside the lockscreen.
Flags: needinfo?(gweng)
OK. I can confirm that the STR in Comment 5 is valid if:

1. Turn on the device
2. Unlock the device as usual
3. Send the commands to the device

And it occurs. So I think the bug is something wrong happens when the settings got set.
Finally I've got the solution. The root cause is the 'unlocked' flag would not be managed properly if we lock the screen in the way FMD uses. I'll submit the patch with test. Although the performance issue still occurs, at least this bug would be solved soon,
Comment on attachment 8575194 [details] [review]
[gaia] snowmantw:bug1139540 > mozilla-b2g:master

Since I submit the patch, set reviewer.
Attachment #8575194 - Flags: review?(timdream)
Attachment #8575194 - Flags: review?(timdream) → review+
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
adding qawanted to verify this on nightly mozilla-central
Keywords: qawanted, verifyme
This issue does not occur on the Flame 3.0 because "Privacy Control" was removed.

Environmental Variables:
Device: Flame 3.0(Full Flash)(KK)(319mb)
BuildID: 20150312010235
Gaia: 0c4e8b0b330757e261b031b7e7f326ef419c9808
Gecko: 5334d2bead3e
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 39.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0

------------------------------------------------------------------

I will check the engineering build once we get a latter one that contains the commit.
This issue is verified fixed on the latest Nightly Engineering Flame 3.0 build.

Actual Results: The phone is still responsive after remote locking it.

Environmental Variables:
Device: Flame 3.0
BuildID: 20150313010238
Gaia: eabe35cf054d47087b37c1ca7db8143717fbd7f3
Gecko: 42afc7ef5ccb
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 39.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+][COM=Privacy Panel] → [QAnalyst-Triage?][COM=Privacy Panel]
Flags: needinfo?(ktucker)
Keywords: qawanted, verifyme
QA Whiteboard: [QAnalyst-Triage?][COM=Privacy Panel] → [QAnalyst-Triage+][COM=Privacy Panel]
Flags: needinfo?(ktucker)
Assignee: nobody → gweng
Target Milestone: --- → 2.2 S8 (20mar)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: