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)
Tracking
(blocking-b2g:2.5+, b2g-v2.2 unaffected, b2g-master fixed)
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
Reporter | ||
Comment 1•9 years ago
|
||
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)
Comment 2•9 years ago
|
||
[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)
Keywords: regressionwindow-wanted
Reporter | ||
Updated•9 years ago
|
Assignee: nobody → ychung
Reporter | ||
Updated•9 years ago
|
Assignee: ychung → nobody
QA Contact: ychung
Reporter | ||
Comment 3•9 years ago
|
||
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)
Keywords: regressionwindow-wanted
Reporter | ||
Updated•9 years ago
|
QA Contact: ychung
Comment 4•9 years ago
|
||
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)
Assignee | ||
Comment 5•9 years ago
|
||
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)
Assignee | ||
Comment 6•9 years ago
|
||
I've found if 'lockscreen.lock-immediately' fired after 'lockscreen.enabled', as the normal sequence user would follow, the bug disappeared.
Assignee | ||
Comment 7•9 years ago
|
||
Hmm...the way I've mentioned at Comment 5 is invalid now. Need to find new programmatic way to debug this.
Assignee | ||
Comment 8•9 years ago
|
||
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)
Comment 9•9 years ago
|
||
Adding qawanted in regards to Comment 8.
Flags: needinfo?(ktucker)
Keywords: qawanted
Reporter | ||
Updated•9 years ago
|
QA Contact: ychung
Reporter | ||
Comment 10•9 years ago
|
||
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
Updated•9 years ago
|
QA Whiteboard: [QAnalyst-Triage?][COM=Privacy Panel] → [QAnalyst-Triage+][COM=Privacy Panel]
Flags: needinfo?(ktucker)
Comment 11•9 years ago
|
||
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)
Assignee | ||
Comment 12•9 years ago
|
||
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)
Assignee | ||
Comment 13•9 years ago
|
||
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.
Assignee | ||
Comment 14•9 years ago
|
||
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 15•9 years ago
|
||
Assignee | ||
Comment 16•9 years ago
|
||
Comment on attachment 8575194 [details] [review] [gaia] snowmantw:bug1139540 > mozilla-b2g:master Since I submit the patch, set reviewer.
Attachment #8575194 -
Flags: review?(timdream)
Assignee | ||
Comment 17•9 years ago
|
||
And it's green on Try server: https://treeherder.mozilla.org/#/jobs?repo=gaia-try&revision=c89a93466d5b
Updated•9 years ago
|
Attachment #8575194 -
Flags: review?(timdream) → review+
Assignee | ||
Updated•9 years ago
|
Keywords: checkin-needed
Updated•9 years ago
|
Keywords: checkin-needed
Comment 18•9 years ago
|
||
Pull request has landed in master: https://github.com/mozilla-b2g/gaia/commit/228f77fd32e5df0285b2e6ee6bd7a853c00e5b45
Updated•9 years ago
|
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Comment 19•9 years ago
|
||
adding qawanted to verify this on nightly mozilla-central
Comment 20•9 years ago
|
||
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.
Comment 21•9 years ago
|
||
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
Updated•9 years ago
|
QA Whiteboard: [QAnalyst-Triage?][COM=Privacy Panel] → [QAnalyst-Triage+][COM=Privacy Panel]
Flags: needinfo?(ktucker)
Updated•9 years ago
|
Updated•9 years ago
|
status-b2g-v2.5:
--- → fixed
Updated•9 years ago
|
status-b2g-v2.5:
fixed → ---
You need to log in
before you can comment on or make changes to this bug.
Description
•