Closed Bug 1121232 Opened 10 years ago Closed 10 years ago

[Privacy Panel][Remote Privacy Protection] Closing Privacy Panel in the Task Manager prevents first received RPP feature from functioning.

Categories

(Firefox OS Graveyard :: Gaia, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

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

VERIFIED FIXED
2.2 S6 (20feb)
blocking-b2g 2.2+
Tracking Status
b2g-v2.2 --- verified
b2g-master --- verified

People

(Reporter: Marty, Assigned: kgrandon)

References

()

Details

(Keywords: privacy, Whiteboard: [3.0-Daily-Testing])

Attachments

(4 files)

Description: If the user Closes the Privacy Panel in the Task Manager, the next received RPP function (Locate, Ring, Lock) will not work, but instead will be received like an ordinary SMS. With the receipt of the SMS, the Privacy Panel will launch in the background, and any further RPP functions received will then function properly, unless the Privacy Panel is closed in the Task Manager again. Repro Steps: 1) Update a device to BuildID: 20150113010202 2) Open Settings and navigate to Privacy Panel. 3) Progress past the Guided Tour, and select Remote Privacy Protection 4) Configure a Passphrase and enable the RPP Lock function 5) Long-Press the Home button to open Task Manager and Swipe Up to close Privacy Panel. 6) From a second device, send 'RPP lock <PASSPHRASE>' in an SMS to the DUT 7) Re-send the same SMS to the DUT Actual: The first RPP Function will not work after Privacy Panel is closed in the Task Manager. The second RPP Function will work after Privacy Panel re-starts in the background. Expected: Received RPP Functions will always work when enabled in the Privacy Panel. Environmental Variables: Device: 3.0 BuildID: 20150113010202 Gaia: 9946a490a9264b42e65385d703b28fa055ab2d42 Gecko: 3d846527576f Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76 Version: 38.0a1 (3.0) Firmware: V18D-1 User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0 Repro frequency: 8/8 See attached: video clip (URL), logcat ------------------------------ This issue DOES occur on Flame 2.2 RPP Functions will not work after Privacy Panel is closed in the Task Manager until Privacy Panel re-starts in the background. Environmental Variables: Device: Flame KK BuildID: 20150112010228 Gaia: f5e481d4caf9ffa561720a6fc9cf521a28bd8439 Gecko: bb8d6034f5f2 Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76 Version: 37.0a1 (KK) Firmware: V18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 ------------------------------ This issue does NOT occur on Flame 2.1 Privacy Panel was not implemented on this branch. Environmental Variables: Device: Flame 2.1 BuildID: 20150112001215 Gaia: 1975241ac29f723479e6c60b2bf74ebed54da91a Gecko: 0863fe4b75c3 Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76 Version: 34.0 (2.1) Firmware: V18D User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga)
blocking-b2g: --- → 2.2?
Here's a possible fix which waits until all settings have been observed before calling events. I think we might be missing a few settings calls here. If that's the case, this might fix it.
NI EPM for nominating 2.2 blocker.
Flags: needinfo?(jocheng)
Hi Kevin, Thanks for the help here. I think this is blocker because function broken. Will you take this bug? Thanks!
blocking-b2g: 2.2? → 2.2+
Flags: needinfo?(jocheng)
Kevin, any suggestions how to proceed?
Flags: needinfo?(kgrandon)
I'm not sure where we stand here. Is it still broken even with the patch? It seems like that fixes at least 1 race condition, but maybe there are more?
Flags: needinfo?(kgrandon)
Hi Kevin, Sorry for late response. I've tried your patch and RPP feature can work well after closing Privacy Panel in the Task Manager.
Comment on attachment 8557861 [details] [review] [PullReq] martasect:Bug_1121232 to mozilla-b2g:master Can you r+ Josh?
Attachment #8557861 - Flags: review?(jocheng)
Hi Marta, I am not sure I am the right one to review the patch as I majorly focus on PM side of work. Do you know who else can review the code?
Flags: needinfo?(marta)
Kevin? I mean its mostly your code so not sure who should review it....
Flags: needinfo?(marta) → needinfo?(kgrandon)
*shrug* I don't really remember writing it, but I can review it if you want, or if it *is* 100% my code, then you could even review it if you wanted? I know it fixed at least 1 race condition, not sure if it fixed the issue though? Feel free to change the flag to me if that makes sense. I'm fine going either way here.
Flags: needinfo?(kgrandon)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][COM=Privacy Panel]
Comment on attachment 8557861 [details] [review] [PullReq] martasect:Bug_1121232 to mozilla-b2g:master Hi Kevin, Thanks for the help!
Attachment #8557861 - Flags: review?(jocheng) → review?(kgrandon)
Comment on attachment 8557861 [details] [review] [PullReq] martasect:Bug_1121232 to mozilla-b2g:master Let's let Marta respond to comment 11. I'm not sure what % of this patch is mine, or if it fixes the problem in this bug.
Attachment #8557861 - Flags: review?(kgrandon)
It is the code we worked on in SF, and the patch you proposed applied to the master. And as per comment 6, the patch works.
Flags: needinfo?(kgrandon)
Comment on attachment 8557861 [details] [review] [PullReq] martasect:Bug_1121232 to mozilla-b2g:master Sounds good. I'll go ahead and leave an R+ on this attachment then.
Flags: needinfo?(kgrandon)
Attachment #8557861 - Flags: review+
Kgrandon, can you help if this is ready to land?
Flags: needinfo?(kgrandon)
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(kgrandon)
Resolution: --- → FIXED
Comment on attachment 8557861 [details] [review] [PullReq] martasect:Bug_1121232 to mozilla-b2g:master Requesting 2.2 for this privacy panel fix. [Approval Request Comment] [Bug caused by] (feature/regressing bug #): Feature implementation. [User impact] if declined: Poor experience using privacy panel. [Testing completed]: Manual testing by Marta and Gerry. [Risk to taking this patch] (and alternatives if risky): Looking at the code it seems functional and only one file was changed so it should be low risk. [String changes made]: No.
Attachment #8557861 - Flags: approval-gaia-v2.2?(bbajaj)
Please request Gaia v2.2 approval on this when you get a chance.
Assignee: nobody → kgrandon
Flags: needinfo?(kgrandon)
Target Milestone: --- → 2.2 S6 (20feb)
(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #19) > Please request Gaia v2.2 approval on this when you get a chance. Done in comment 18 :)
Flags: needinfo?(kgrandon)
Attachment #8557861 - Flags: approval-gaia-v2.2?(bbajaj) → approval-gaia-v2.2+
Keywords: verifyme
This issue has been successfully verified on flame 3.0 Device:Flame 3.0 Build ID 20150331160205 Gaia Revision 03164bd160809747e6a198e0dba1b7c3ee7789f5 Gaia Date 2015-03-31 14:48:14 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/18a8ea7c2c62 Gecko Version 40.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150331.191641 Firmware Date Tue Mar 31 19:16:50 EDT 2015 Bootloader L1TC000118D0 But it is failed verified on flame 2.2 Device: Flame 2.2 Build ID 20150331002503 Gaia Revision cc11248ab69f13e89416c8e6bb2e184187e72088 Gaia Date 2015-03-30 22:22:58 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/90a26917ee8f Gecko Version 37.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150331.034811 Firmware Date Tue Mar 31 03:48:21 EDT 2015 Bootloader L1TC000118D0 Hi Ryan, could you help to check this issue agian?
Flags: needinfo?(ryanvm)
Attached image 2015-03-31-22-34-28.png
As in attached figure, we recieve the message first time, the screen will not be locked, if we resend this code agian, the device will be locked after few second later.
That's a question for the bug assignee.
Flags: needinfo?(ryanvm) → needinfo?(kgrandon)
I probably won't have time to get to this in 2.2 unfortunately. Marta - could you by chance look into 2.2? Not sure why it wouldn't work there, are we missing other privacy panel patches from 2.2?
Flags: needinfo?(kgrandon) → needinfo?(marta)
I'm currently requesting uplifting other PP patches. Lets see if that helps
Flags: needinfo?(marta)
This issue is verified fixed on Flame 2.2. I notice a lag of a few seconds between receiving text and performing the action (lock/ring/locate)(though I don't know what 'locate' actually does, it seems to only turn on receiving device's Geolocation for several seconds but I don't see any feedback on sending device), but it does perform the first texted action on receiving end after they killed privacy controls. Device: Flame 2.2 (319MB) BuildID: 20151022033039 Gaia: 885647d92208fb67574ced44004ab2f29d23cb45 Gecko: 7bc753230036 Gonk: bd9cb3af2a0354577a6903917bc826489050b40d Version: 37.0 (2.2) Firmware Version: v18Dv4 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+][COM=Privacy Panel] → [QAnalyst-Triage?][COM=Privacy Panel]
Flags: needinfo?(jmercado)
Keywords: verifyme
QA Whiteboard: [QAnalyst-Triage?][COM=Privacy Panel] → [QAnalyst-Triage+][COM=Privacy Panel]
Flags: needinfo?(jmercado)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: