Closed Bug 1000173 Opened 8 years ago Closed 8 years ago

Display a user visible icon when remotely enabling Where's My Fox / Find My Device


(Firefox OS Graveyard :: FindMyDevice, defect)

Not set


(blocking-b2g:-, feature-b2g:2.0, b2g-v2.0 fixed, b2g-v2.1 fixed)

2.0 S5 (4july)
blocking-b2g -
feature-b2g 2.0
Tracking Status
b2g-v2.0 --- fixed
b2g-v2.1 --- fixed


(Reporter: curtisk, Assigned: kglazko)



(Keywords: late-l10n)


(3 files, 1 obsolete file)

When a user enables this feature we may want to display a user visible icon in the notification area that the feature is enabled. This would alter users if someone has enabled the feature for them without their knowledge. However this may also alter attackers the feature is enabled and prompt them to power off the phone. 
Discussion of this was in the public comment thread (!topic/ for the privacy review and the thinking is we should make a definitive decision on the feature as this has implications for domestic violence situations.
Summary: Display a user visible icon when enableing Where's My Fox / Find My Device → Display a user visible icon when remotely enabling Where's My Fox / Find My Device
Assigning to Bryan Bell who is leading the charge on vis design of the website.
Assignee: nobody → bryan
Apologies, I reversed this. Not for web; for device UX. She'll check on notifications vs status bar.
Assignee: bryan → jsavory
Target Milestone: --- → 2.0 S3 (6june)
Is this landing tomorrow?
It doesn't look like it...
Target Milestone: 2.0 S3 (6june) → 2.0 S4 (20june)
Looking at our options, I don't think that either the notifications or status bar will work for this problem. 

Erin has suggested we look into including this in settings and I will work on a proposal for an active state in the Find my Device settings.
blocking-b2g: --- → 2.0?
This looks like missed feature work, so tagging it accordingly
blocking-b2g: 2.0? → -
feature-b2g: --- → 2.0
I've attached the spec for the notification within settings to show the user if they are actively being tracked by the website. Let me know if there are any questions.
Assignee: jsavory → kglazko
Attached file Pull Request (obsolete) —
Depends on: 1027429
Attachment #8440067 - Flags: review?(arthur.chen)
Keywords: late-l10n
Hey guys, the string freeze for 2.0 was today, if it's ready please land it ASAP (likely this weekend) if you want it to make it for 2.0, otherwise contact the l10n team. Thanks
Attached file gaia pull request
Kate, thank you so much for working on this. Great job!

I took another look at the patch today, because we're trying to get it landed ASAP, and there were still some final details to be fixed, so I addressed them. I'm attaching a new pull request; it's green on my private Travis instance:

Arthur, the priority here is to get the strings landed, so I'll be happy to postpone the code changes and provide a patch containing only the strings if you think that's better. Thank you!
Attachment #8440067 - Attachment is obsolete: true
Attachment #8440067 - Flags: review?(arthur.chen)
Attachment #8443938 - Flags: review?(arthur.chen)
Comment on attachment 8443938 [details] [review]
gaia pull request

r=me with the comment addressed, thanks!
Attachment #8443938 - Flags: review?(arthur.chen) → review+
Done, thank you!
Keywords: checkin-needed
Hi Guilherme,

We should also update the unit tests. Please check my comments in github.
Actually, let's hold this back for a moment. I'm having issues with FxA that are preventing me from testing this, and Arthur just pointed out I broke the unit tests :/
Keywords: checkin-needed
Looking better now I think. The unit tests pass locally, and I was able to hack FxA enough to do some manual testing too. Apologies for messing up on the first time, I'll set checkin-needed once I get an actual green Travis.
PR updated to reflect Arthur's comments about mocking navigator.mozL10n.localize. Thanks for that! :)
Closed: 8 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: 2.0 S4 (20june) → 2.0 S5 (4july)
Comment on attachment 8443938 [details] [review]
gaia pull request

NOTE: Please see to better understand the B2G approval process and landings.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #):
[User impact] if declined: This poses a privacy concern as the user won't be able to know if he's being tracked without consent
[Testing completed]: Travis and manual.
[Risk to taking this patch] (and alternatives if risky): No risk.
[String changes made]: Two strings were added to the Settings app.
Attachment #8443938 - Flags: approval-gaia-v2.0?(bbajaj)
a=bajaj for the patch. We have an ongoing discussion with the l10n team to get this landed by monday morning am, I am flagging :pike/:flod to give a formal l10n approval before I go ahead and approve this patch.
Flags: needinfo?(l10n)
Flags: needinfo?(francesco.lodolo)
Neither flod nor I are the people to talk here.

If you wanted feedback, it'd probably be by chofmann. Not to take too many of his words out of his mouth, but the plan was to be done on Friday. That plan didn't work out. You need a new plan, and create a schedule out of it.

Individual bugs don't matter beyond technical regressions introduced by them.
Flags: needinfo?(l10n)
Flags: needinfo?(francesco.lodolo)
Flags: needinfo?(christian.hoffmann)
Erin, I don't understand why folks insist on asking for feedback on this bug.

We need a plan now that we busted string freeze, and this bug is only one of a few.

Also redirecting the feedback request to the right chofmann.
Flags: needinfo?(christian.hoffmann) → needinfo?(chofmann)
We just had a talk with Erin and Chris, I think we now are on the same page. Let's land that and get a new string freeze date from Release Management.
Flags: needinfo?(chofmann)
+1. We've deferred all non-critical string changes. This one, we just really need to have. Please uplift accordingly and we don't take this kind of uplift lightly. With this landing, we're string frozen for Find My Device for 2.0. Thank you.
Attachment #8443938 - Flags: approval-gaia-v2.0?(bbajaj) → approval-gaia-v2.0+
This is failing Gaia unit tests.

I have to run now, but I will revert this when I get home if the failures aren't addressed in the mean time.
I think it should be fine to revert for now, and I expect the issue to be gone if we uplift bug 1022992 before this one.

The test is failing because this patch doesn't expect apps/settings/js/findmydevice.js to depend on navigator.mozL10n.get, but that dependence was removed by bug 1022992.
This backed out strings post string freeze. Can we get an estimate on when this can be landed again?
Bug 1022992 doesn't cherry-pick cleanly on its own and it's too late for me to look at it today. It's very possible that it will cherry-pick OK once I get caught up on the 30+ other patches currently backlogged on v2.0 uplift from my recent PTO. I'll try again tomorrow morning EDT.
Arthur, are we good to request approval for aurora uplift?
Flags: needinfo?(arthur.chen)
Whiteboard: upliftneeded
Flags: needinfo?(arthur.chen)
Whiteboard: upliftneeded
You need to log in before you can comment on or make changes to this bug.