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)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.2+, b2g-v2.2 verified, b2g-master unaffected)

VERIFIED FIXED
2.2 S8 (20mar)
blocking-b2g 2.2+
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
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)
NI developer for this.
Flags: needinfo?(gchang) → needinfo?(gweng)
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)
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'); };
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][COM=Privacy Panel]
Hi Arthur, I'm not sure who the right owner is. Can you help to dispatch?
Flags: needinfo?(arthur.chen)
Greg, per comment 5, could you check whether lockscreen is invoked in a propery way with Marta? Thanks.
Flags: needinfo?(arthur.chen) → needinfo?(gweng)
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)
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)
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)
Flags: needinfo?(arthur.chen)
(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.
No longer blocks: Privacy_Control
Hi Howie, Could you help to triage this issue in 2.2? Thanks!
blocking-b2g: --- → 2.2?
Flags: needinfo?(hochang)
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
QA Contact: ychung
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
Let's get a fix window then.
QA Whiteboard: [QAnalyst-Triage?][COM=Privacy Panel] → [QAnalyst-Triage+][COM=Privacy Panel]
Flags: needinfo?(ktucker)
QA Contact: pcheng
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.
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)
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)
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)
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!
blocking-b2g: 2.2? → 2.2+
Hi Greg, we'll need your help on this one. thanks.
Flags: needinfo?(gweng)
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 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)
Attachment #8576463 - Flags: review?(timdream) → review+
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)
Assignee: nobody → gweng
Keywords: checkin-needed
Attachment #8576463 - Flags: approval-gaia-v2.2?(bbajaj) → approval-gaia-v2.2+
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.
Keywords: checkin-needed
Keywords: checkin-needed
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.
Hmm the error is somewhat Docker error on TaskCluster. It's apparently irrelevant to Gaia-Try, and I may manually land this patch.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.2 S8 (20mar)
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
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: