Lockscreen will not show accurate time after receiving RPP Lock command.

VERIFIED FIXED in 2.2 S8 (20mar)

Status

defect
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: Marty, Assigned: gweng)

Tracking

({privacy})

unspecified
2.2 S8 (20mar)
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

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

Details

(Whiteboard: [3.0-Daily-Testing], URL)

Attachments

(3 attachments)

(Reporter)

Description

4 years ago
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

4 years ago
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.

Comment 5

4 years ago
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)

Updated

4 years ago
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.

Updated

4 years ago
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)

Comment 13

4 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
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+

Comment 21

4 years ago
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)
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

4 years ago
Assignee: nobody → gweng
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.
(Assignee)

Updated

4 years ago
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.
v2.2: https://github.com/mozilla-b2g/gaia/commit/086f7c2cddb38e4c09efbb02b2147bfa696ae292
Status: NEW → RESOLVED
Last Resolved: 4 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.