KidFox: Restricted profiles - Hide all Location Services features and related UI

VERIFIED FIXED in Firefox 42

Status

()

defect
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: jchaulk, Assigned: sebastian)

Tracking

Trunk
Firefox 42
All
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox42 verified)

Details

Attachments

(1 attachment, 1 obsolete attachment)

Comment hidden (empty)
Blocks: FFB
OS: Windows 8.1 → Android
Hardware: x86_64 → All
Version: unspecified → Trunk
(Reporter)

Updated

4 years ago
Blocks: kidfox-v1
Assignee: nobody → s.kaspari
Status: NEW → ASSIGNED
We already have a constant to enable/disable location services at build time. And wherever this constant is used I added the restriction check too.
Attachment #8640464 - Flags: review?(margaret.leibovic)
Depends on: 1187260
Comment on attachment 8640464 [details] [diff] [review]
1125309-location-services.patch

Review of attachment 8640464 [details] [diff] [review]:
-----------------------------------------------------------------

::: mobile/android/base/preferences/GeckoPreferences.java
@@ +765,5 @@
>                          continue;
>                      }
>                  } else if (PREFS_GEO_REPORTING.equals(key) ||
>                             PREFS_GEO_LEARN_MORE.equals(key)) {
> +                    if (!AppConstants.MOZ_STUMBLER_BUILD_TIME_ENABLED || !RestrictedProfiles.isAllowed(this, Restriction.DISALLOW_LOCATION_SERVICE)) {

Just to confirm, this pref is disabled by default, so we don't need to worry about actually flipping the pref here?

Is this setting per-profile or per-app? We confirm this doesn't persist if someone flips this to true in a normal profile, then later opens the browser in a restricted profile. Or maybe since the admin would need to be doing that in the normal profile, they're fine with sharing this data and we don't care.

::: mobile/android/base/restrictions/Restriction.java
@@ +86,5 @@
> +
> +    DISALLOW_LOCATION_SERVICE(
> +            17, "no_location_service",
> +            R.string.restriction_disallow_location_services_title,
> +            R.string.restriction_disallow_location_services_description

Do we also need to add this to nsIParentalControlsService.idl?
Attachment #8640464 - Flags: review?(margaret.leibovic) → review+
(In reply to :Margaret Leibovic from comment #2)
> Just to confirm, this pref is disabled by default, so we don't need to worry
> about actually flipping the pref here?

Correct. And it's short-circuited in BrowserApp.


(In reply to :Margaret Leibovic from comment #2)
> Is this setting per-profile or per-app? We confirm this doesn't persist if
> someone flips this to true in a normal profile, then later opens the browser
> in a restricted profile. Or maybe since the admin would need to be doing
> that in the normal profile, they're fine with sharing this data and we don't
> care.

The restricted profile is treated like a totally independent installation of the app. They share no data.


(In reply to :Margaret Leibovic from comment #2)
> ::: mobile/android/base/restrictions/Restriction.java
> @@ +86,5 @@
> > +
> > +    DISALLOW_LOCATION_SERVICE(
> > +            17, "no_location_service",
> > +            R.string.restriction_disallow_location_services_title,
> > +            R.string.restriction_disallow_location_services_description
> 
> Do we also need to add this to nsIParentalControlsService.idl?

Oh yeah, we should keep them in sync. I'll update the patch.
Updated patch addressing the review comments.
Attachment #8640464 - Attachment is obsolete: true
Attachment #8641025 - Flags: review+
url:        https://hg.mozilla.org/integration/fx-team/rev/0f5b42aa89276bcffcce2728507a4c7626b7be95
changeset:  0f5b42aa89276bcffcce2728507a4c7626b7be95
user:       Sebastian Kaspari <s.kaspari@gmail.com>
date:       Thu Jul 30 20:18:03 2015 +0200
description:
Bug 1125309 - Restricted profiles: Hide all Location Services features and related UI. r=margaret
https://hg.mozilla.org/mozilla-central/rev/0f5b42aa8927
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 42
Verified as fixed on Nightly and Aurora
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.