From: Sarah Jamie Lewis <sarah@openprivacy.ca>
When the parental controls service is disabled in a build, the DoH
settings now display the correct stauts when Increased or Max Protection
is enabled.
Previously, selecting either of these options would cause DoH to be
enabled, but the "Status" and "Provider" fields would not be properly
populated, due to a check on the gParentalControlsService causing an
error.
This check is now identical to the same check in DownloadIntegration.sys.mjs
Apply 1 suggestion(s) to 1 file(s)
Co-authored-by: ma1 <giorgio@maone.net>
Differential Revision: https://phabricator.services.mozilla.com/D244850
Please see the bug for the motivation.
This adds a new `SuggestFeature.primaryUserControlledPreference` getter that
returns the feature-specific pref that lets the user toggle on/off the feature.
That way we can add `QuickSuggest.clearDismissedSuggestions()`, which goes
through each feature and clears that pref, and `canClearDismissedSuggestions()`,
which goes through and checks whether there are any prefs that can be cleared.
I also added a couple of notification topics for dismissals that the settings UI
uses to update the disabled state of its Restore button.
All of this will let us more easily move to the Suggest Rust component's
dismissal API too, which we should sooner or later.
Depends on D244865
Differential Revision: https://phabricator.services.mozilla.com/D244866
This makes the following primary changes to the Suggest settings in the search
pane:
* Remove the infobox
* Remove the learn-more link from the dismissed-suggestions description
* Add a learn-more link to the Address Bar section's description but show it
only when Suggest is enabled
* Add `#w_what-setting-is-opt-in` fragment to the learn-more URL for the online
toggle so it links directly to the appropriate section
It also makes these related changes:
Remove the unnecessary `vbox` containers for the toggle switches. I had to
modify some reusable-components CSS. Note that there are two copies of the
Suggest toggle, one in the search pane and one in the privacy pane.
Rename the sponsored and nonsponsored checkbox strings so they're consistent
with the other checkbox strings: `addressbar-locbar-foo-option`
Remove test tasks that click checkboxes and make sure the appropriate prefs are
updated and vice versa. Now that the infobox is gone, there's no need for
Suggest-specific tests to worry about that.
Similarly, remove test tasks that click the learn-more links and make sure the
right page is opened. No need for Suggest-specific tests to do that either.
Differential Revision: https://phabricator.services.mozilla.com/D238847
This replaces `quickSuggestHideSettingsUI` with `quickSuggestSettingsUi`. Like
the old variable, we can show or hide all Suggest settings UI, and now we can
also hide UI that pertains only to Suggest online. This is necessary because as
we start to roll out Suggest to more regions, online (Merino) won't be available
for them initially.
Differential Revision: https://phabricator.services.mozilla.com/D238159
This replaces `quickSuggestHideSettingsUI` with `quickSuggestSettingsUi`. Like
the old variable, we can show or hide all Suggest settings UI, and now we can
also hide UI that pertains only to Suggest online. This is necessary because as
we start to roll out Suggest to more regions, online (Merino) won't be available
for them initially.
Differential Revision: https://phabricator.services.mozilla.com/D238159
This makes `browser_search_firefoxSuggest.js` more realistic by installing a
Nimbus experiment to change the Suggest scenario instead of manually setting the
scenario via the helper function. (The "scenario" just means whether Suggest is
enabled or not, basically. "history" means it's not enabled; "offline" and
"online" mean it's enabled. The difference between the latter two is that in
"online" the user has opted in to the Merino server, and that only means one of
the Suggest prefs is true instead of false.)
I noticed `browser_privacy_firefoxSuggest.js` does not check the visibility of
its Suggest section at all, so I added similar tasks to it and factored out the
common helpers into `head.js`.
Depends on D221097
Differential Revision: https://phabricator.services.mozilla.com/D221099
Disabling `MOZ_DATA_REPORTING` results in the `PREF_UPLOAD_ENABLED` pref not
being loaded with `Preferences.add`. This means
`Preferences.get(PREF_UPLOAD_ENABLED)` can possibly be `null`, which was
previously not handled and resulted in an error for the whole privacy.js file.
So only call `dataCollectionCheckboxHandler` for the `privateAttribution`
checkbox if `MOZ_DATA_REPORTING` is enabled (otherwise the `privateAttribution`
checkbox also just doesn't exist). Also move the call into separate
`initPrivateAttributionCheckbox` function to be more consistent with previous
code.
Differential Revision: https://phabricator.services.mozilla.com/D218265
In light of us being in the process of enabling HTTPS-First by default, these strings have been proposed by content design to make it more clear to the user that if they disable HTTPS-Only, upgrades may still be happening.
The description generally has been updated, but the labels for the radio buttons only get the new strings in this patch when HTTPS-First is also enabled.
Differential Revision: https://phabricator.services.mozilla.com/D216381
Right now the UI state for PPA remains checked and active even when the main telemetry
setting is disabled. This is confusing UX, since DAP submission is disabled when
telemetry is disabled.
Also migrate off the deprecated toolkit-private isTelemetryEnabled() accessor to the normal pref check.
Differential Revision: https://phabricator.services.mozilla.com/D216801
