Closed
Bug 1122298
Opened 10 years ago
Closed 10 years ago
Lockscreen will not show accurate time after receiving RPP Lock command.
Categories
(Firefox OS Graveyard :: Gaia::System::Lockscreen, defect)
Tracking
(blocking-b2g:2.2+, b2g-v2.2 verified, b2g-master unaffected)
Tracking | Status | |
---|---|---|
b2g-v2.2 | --- | verified |
b2g-master | --- | unaffected |
People
(Reporter: Marty, Assigned: gweng)
References
()
Details
(Keywords: privacy, Whiteboard: [3.0-Daily-Testing])
Attachments
(3 files)
Description:
If the device receives a RPP Lock command, the resultant lock screen will not show the accurate time. It will instead show the time from the last time the device was at the lock screen.
Repro Steps:
1) Update a Flame device to BuildID: 20150115010229
2) Lock the device and note the time.
3) Unlock the device, open the Settings app, and select Privacy Panel
4) Dismiss the Guided Tour and select Remote Privacy Protection
5) Configure your passphrase and set up a lock screen passcode if needed.
6) Enable the RPP Lock function.
7) From another device, send 'RPP lock <PASSPHRASE>' in an SMS to the DUT
Actual:
The user is brought to a lock screen that displays the previously viewed time, not the current time.
Expected:
The user is brought to a lock screen that displays the correct time.
Environmental Variables:
Device: Flame 3.0 Master (319MB) (Full Flash)
BuildID: 20150115010229
Gaia: bcc76f93f5659ac1eb8a769167109fd2d7ca4fbd
Gecko: c1f6345f2803
Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76
Version: 38.0a1 (3.0 Master)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0
Repro frequency: 5/5
See attached: video clip (URL), logcat
----------------------------------------------
This issue DOES occur in Flame 2.2.
The user is brought to a lock screen that displays the previously viewed time, not the current time.
Environmental Variables:
Device: Flame 2.2
BuildID: 20150115002505
Gaia: 7c5b27cad370db377b18a742d3f3fdb0070e899f
Gecko: ce27f2692382
Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76
Version: 37.0a2 (2.2)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
----------------------------------------------
This issue does NOT occur in Flame 2.1
Privacy Panel was not implemented on this branch.
Environmental Variables:
Device: Flame 2.1
BuildID: 20150115001207
Gaia: 8d4846d7bec777046dc5e3d2b8005adb1370f1f7
Gecko: 8eb9bc3a945a
Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76
Version: 34.0 (2.1)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Reporter | ||
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Comment 1•10 years ago
|
||
Moving this to lockscreen component.
NI on component owner for nomination decision and assignment.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Component: Gaia → Gaia::System::Lockscreen
Flags: needinfo?(pbylenga) → needinfo?(gchang)
Assignee | ||
Comment 3•10 years ago
|
||
What is Privacy Panel (as I suppose you're not familiar with LockScreen) and what's the connection between LockScreen and it?
Flags: needinfo?(gweng)
Assignee | ||
Comment 4•10 years ago
|
||
I never get in the development of Private Panel and no one info me about why and how it's related with LockScreen. So if you expect me to solve the bug immediately something must be wrong.
I dont see any part of the PP code that would cause that. All we do is invoke the Lockscreen command. And actually the file is identical to fmD file.
lock: function fmdc_lock(message, passcode, reply) {
var settings = {
'lockscreen.enabled': true,
'lockscreen.notifications-preview.enabled': false,
'lockscreen.passcode-lock.enabled': true,
'lockscreen.lock-immediately': true
};
if (message) {
settings['lockscreen.lock-message'] = message;
}
if (!this.deviceHasPasscode() && passcode) {
settings['lockscreen.passcode-lock.code'] = passcode;
}
var request = SettingsListener.getSettingsLock().set(settings);
request.onsuccess = function() {
reply(true);
};
request.onerror = function() {
reply(false, 'failed to set settings');
};
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][COM=Privacy Panel]
Comment 6•10 years ago
|
||
Hi Arthur,
I'm not sure who the right owner is. Can you help to dispatch?
Flags: needinfo?(arthur.chen)
Comment 7•10 years ago
|
||
Greg, per comment 5, could you check whether lockscreen is invoked in a propery way with Marta? Thanks.
Flags: needinfo?(arthur.chen) → needinfo?(gweng)
Assignee | ||
Comment 8•10 years ago
|
||
I don't see any code may be the cause of this bug in the Comment 5... It's totally irrelevant with the part about the clock.
Flags: needinfo?(gweng)
Comment 9•10 years ago
|
||
I'm able to reproduce with a simplified scenario without privacy panel being involved:
1. Enable screen lock in settings app.
2. Press power button twice to make the lockscreen displayed on the screen.
3. Unlock the phone and wait for 1 minute.
4. Set 'lockscreen.lock-immediately' to true and observe the time displayed on the lockscreen.
Actual result: The time is the same as the value observed in step 2.
Expected result: The time should be the current time.
Greg, could you help confirm if this is valid?
Flags: needinfo?(gweng)
Assignee | ||
Comment 10•10 years ago
|
||
I'll suggest to create a new bug totally irrelevant to Privacy Panel to make the bug status more clear, than I could do some test according to it.
Flags: needinfo?(gweng)
Updated•10 years ago
|
Flags: needinfo?(arthur.chen)
Comment 11•10 years ago
|
||
(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #10)
> I'll suggest to create a new bug totally irrelevant to Privacy Panel to make
> the bug status more clear, than I could do some test according to it.
As the STR in the description seems the only way of reproducing the issue, let's still track it using this bug. I've remove the "privacy panel" word from the title.
Flags: needinfo?(arthur.chen)
Summary: [Privacy Panel][Remote Privacy Protection] Lockscreen will not show accurate time after receiving RPP Lock command. → Lockscreen will not show accurate time after receiving RPP Lock command.
Updated•10 years ago
|
No longer blocks: Privacy_Control
Comment 12•10 years ago
|
||
Hi Howie,
Could you help to triage this issue in 2.2? Thanks!
blocking-b2g: --- → 2.2?
Flags: needinfo?(hochang)
Comment 13•10 years ago
|
||
qawanted to check if this still happens in latest 2.2/3.0 and check if it's related to privacy panel or not.
Flags: needinfo?(hochang)
Keywords: qawanted
Updated•10 years ago
|
QA Contact: ychung
Comment 14•10 years ago
|
||
I was unable to reproduce this issue on Flame Master.
Result: The time on the lockscreen shows the correct time when the device is locked by remote lock.
Repro rate: 0/10
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
==========================================
This issue still reproduces on Flame 2.2.
Result: Sometimes the time on the lockscreen is not updated to the right time when the device is locked by remote lock.
Repro rate: 4/10
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] → [QAnalyst-Triage?][COM=Privacy Panel]
Flags: needinfo?(ktucker)
Keywords: qawanted
QA Contact: ychung
Comment 15•10 years ago
|
||
Let's get a fix window then.
QA Whiteboard: [QAnalyst-Triage?][COM=Privacy Panel] → [QAnalyst-Triage+][COM=Privacy Panel]
Flags: needinfo?(ktucker)
Keywords: regressionwindow-wanted
Updated•10 years ago
|
QA Contact: pcheng
Assignee | ||
Comment 16•10 years ago
|
||
At 3.0 it was fixed with Bug 1115311, which change the way we manage the clock widget. However, of course for v2.2 we need to fix it with a different patch. That is, if PrivacyPanel would ship at v2.2. If not, since it's the only way user could trigger this bug, and it had been fixed at v3.0 (master), the bug will no longer exist in v2.2.
Comment 17•10 years ago
|
||
Confirmed comment 16 that this bug was fixed by patch for bug 1115311. Aside from 2.2 needing a different patch, note that the patch for bug 1115311 also caused bug 1139540, so the 2.2 patch also need to take that into consideration.
b2g-inbound reverse regression window:
Last Broken Environmental Variables:
Device: Flame 3.0 Master
BuildID: 20150223221520
Gaia: 6ac2493449e49622af77c12b4b602cb9c01a66ed
Gecko: 395b88463487
Version: 39.0a1 (3.0 Master)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0
First Working Environmental Variables:
Device: Flame 3.0 Master
BuildID: 20150223225323
Gaia: 123e7e33965c5bfca3238913f2b2828fe77eee9e
Gecko: e75a3c76835a
Version: 39.0a1 (3.0 Master)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0
Last Broken Gaia & First Working Gecko - issue DOES repro
Gaia: 6ac2493449e49622af77c12b4b602cb9c01a66ed
Gecko: e75a3c76835a
Last Broken Gecko & First Working Gaia - issue does NOT repro
Gaia: 123e7e33965c5bfca3238913f2b2828fe77eee9e
Gecko: 395b88463487
Gaia pushlog:
https://github.com/mozilla-b2g/gaia/compare/6ac2493449e49622af77c12b4b602cb9c01a66ed...123e7e33965c5bfca3238913f2b2828fe77eee9e
QA Whiteboard: [QAnalyst-Triage+][COM=Privacy Panel] → [QAnalyst-Triage?][COM=Privacy Panel]
Flags: needinfo?(ktucker)
Keywords: regressionwindow-wanted
Comment 18•10 years ago
|
||
Greg, can you take a look at this please? This issue was fixed on master by the landing for bug 1115311 but that landing caused bug 1139540 so I wouldn't suggest uplifting this fix to 2.2.
QA Whiteboard: [QAnalyst-Triage?][COM=Privacy Panel] → [QAnalyst-Triage+][COM=Privacy Panel]
Flags: needinfo?(ktucker) → needinfo?(gweng)
Assignee | ||
Comment 19•10 years ago
|
||
I don't mean to uplift the patch. It's a big patch and (as you can see) is still in the progress of stabilization. What I meant is I've heard (from my team leader during the last triage) that we don't ship PrivacyPanel in v2.2, so the bug would not be triggered in v2.2. If it would be shipped (so my information is incorrect), than I would fix it.
Flags: needinfo?(gweng)
Comment 20•10 years ago
|
||
Hi Greg,
Thank you for helping this.
Just a comment about "we don't ship PrivacyPanel in v2.2".
Privacy Panel is requested and developed by DT after 2.2 with no other operator nor OEM requested it. The decision is to make it pref off with bug 1132377.
However DT will activate it once they want to launch device with FxOS 2.2. Thus this is still blocking 2.2 for DT.
Thanks!
Blocks: Privacy_Control
Updated•10 years ago
|
blocking-b2g: 2.2? → 2.2+
Assignee | ||
Comment 22•10 years ago
|
||
Yes, yes. This morning I'm just testing another performance bug so I couldn't switch to this one. I'm aware of Comment 20, and would start my work after I finish the started one.
Flags: needinfo?(gweng)
Comment 23•10 years ago
|
||
Assignee | ||
Comment 24•10 years ago
|
||
Comment on attachment 8576463 [details] [review]
[gaia] snowmantw:bug1122298-v2.2 > mozilla-b2g:v2.2
Tim: I've patched it:
1. refresh the clock while the function get invoked
2. re-arrange the code in lockscreen.js to make test works (it's already
broken: always reports false positive result)
Attachment #8576463 -
Flags: review?(timdream)
Updated•10 years ago
|
Attachment #8576463 -
Flags: review?(timdream) → review+
Assignee | ||
Comment 25•10 years ago
|
||
Comment on attachment 8576463 [details] [review]
[gaia] snowmantw:bug1122298-v2.2 > mozilla-b2g:v2.2
[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): LockScreen doesn't update the clock after receiving the command
[User impact] if declined: Bug occurs
[Testing completed]: Try result (green):
https://treeherder.mozilla.org/#/jobs?repo=gaia-try&revision=abec790f4bcc
[Risk to taking this patch] (and alternatives if risky): No
[String changes made]: No
Attachment #8576463 -
Flags: approval-gaia-v2.2?(bbajaj)
Updated•10 years ago
|
Assignee: nobody → gweng
Updated•10 years ago
|
Keywords: checkin-needed,
verifyme
Updated•10 years ago
|
Keywords: checkin-needed
Updated•10 years ago
|
Attachment #8576463 -
Flags: approval-gaia-v2.2?(bbajaj) → approval-gaia-v2.2+
Comment 26•10 years ago
|
||
http://docs.taskcluster.net/tools/task-graph-inspector/#5dILhlm8QBamd6YockaBvQ
The pull request failed to pass integration tests. It could not be landed, please try again.
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Updated•10 years ago
|
Keywords: checkin-needed
Comment 27•10 years ago
|
||
http://docs.taskcluster.net/tools/task-graph-inspector/#vn9g8W7MR3OtZyyJVo83_g
The pull request failed to pass integration tests. It could not be landed, please try again.
Assignee | ||
Comment 28•10 years ago
|
||
Hmm the error is somewhat Docker error on TaskCluster. It's apparently irrelevant to Gaia-Try, and I may manually land this patch.
Comment 29•10 years ago
|
||
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.2 S8 (20mar)
Comment 30•9 years ago
|
||
This bug has been verified as pass on latest build of Flame2.2 by the STR in description.
Rate:0/5
Device:Flame2.2[Verified]
Build ID 20150619002501
Gaia Revision 1c33072e33c279c8aa5cb5e4a3e4da6af6cd818b
Gaia Date 2015-06-19 01:36:47
Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/5ad34a170633
Gecko Version 37.0
Device Name flame
Firmware(Release) 4.4.2
Firmware(Incremental) eng.cltbld.20150619.042950
Firmware Date Fri Jun 19 04:30:02 EDT 2015
Bootloader L1TC000118D0
Device:Nexus5 2.2[Verified]
Build ID 20150621002506
Gaia Revision 1f8981d7872e3c0053571c26fb3edaf401844d75
Gaia Date 2015-06-19 13:22:30
Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/9a0d8f7b1200
Gecko Version 37.0
Device Name hammerhead
Firmware(Release) 5.1
Firmware(Incremental) eng.cltbld.20150621.035418
Firmware Date Sun Jun 21 03:54:36 EDT 2015
Bootloader HHZ12f
Status: RESOLVED → VERIFIED
Comment 31•9 years ago
|
||
You need to log in
before you can comment on or make changes to this bug.
Description
•