We surface the email tracking protection using the existing tracking
protection UI on the protection panel, but we don't disable email
tracking protection if tracking protection is disabled. So, users will
still see blocked trackers if tracking protection is disabled for
private windows. To provide a way to disable email tracking protection
in private windows, we also use the existing tracking protection checkbox
UI to disable the email tracking protection.
This patch implements that disabling the tracking protection via the
tracking protection checkbox also disables email tracking protection.
Differential Revision: https://phabricator.services.mozilla.com/D177520
This adapts previous test cases from the connection UI to the privacy UI.
Additional improvements:
- Set the ROLLOUT_URI_Pref to empty string to avoid DoHConfig reset setting it to undefined.
- Always set network.trr.uri even if it matches the default_provider_uri if it's a user choice.
- If the value of network.trr.uri doesn't match any of the providers, then set custom_uri so
it shows up in the input text field. This can happen when it's set by a policy.
Differential Revision: https://phabricator.services.mozilla.com/D174876
- Patch changes TRRService::MaybeSetPrivateURI so that it doesn't bail
if the URL is invalid. That could lead us into a state where the
network.trr.uri pref has been set to some invalid URL, but we continue
using the previous domain (or even the default TRR provider) instead.
- Updates the DoH settings UI to not set the network.trr.uri pref to "",
as that will cause the TRRService to use the value of
the network.trr.default_provider_uri pref instead.
Differential Revision: https://phabricator.services.mozilla.com/D174111
- The patch saves the confirmation channel's status and skipReason in the TRR Service
- The UI queries the status and displays the stringified version in the Not Available (reason) label
- Introduces doh-status-label CSS rule so the Learn-More link isn't off center
Differential Revision: https://phabricator.services.mozilla.com/D174110
- Patch changes TRRService::MaybeSetPrivateURI so that it doesn't bail
if the URL is invalid. That could lead us into a state where the
network.trr.uri pref has been set to some invalid URL, but we continue
using the previous domain (or even the default TRR provider) instead.
- Updates the DoH settings UI to not set the network.trr.uri pref to "",
as that will cause the TRRService to use the value of
the network.trr.default_provider_uri pref instead.
Differential Revision: https://phabricator.services.mozilla.com/D174111
- The patch saves the confirmation channel's status and skipReason in the TRR Service
- The UI queries the status and displays the stringified version in the Not Available (reason) label
- Introduces doh-status-label CSS rule so the Learn-More link isn't off center
Differential Revision: https://phabricator.services.mozilla.com/D174110
- Patch changes TRRService::MaybeSetPrivateURI so that it doesn't bail
if the URL is invalid. That could lead us into a state where the
network.trr.uri pref has been set to some invalid URL, but we continue
using the previous domain (or even the default TRR provider) instead.
- Updates the DoH settings UI to not set the network.trr.uri pref to "",
as that will cause the TRRService to use the value of
the network.trr.default_provider_uri pref instead.
Differential Revision: https://phabricator.services.mozilla.com/D174111
- The patch saves the confirmation channel's status and skipReason in the TRR Service
- The UI queries the status and displays the stringified version in the Not Available (reason) label
- Introduces doh-status-label CSS rule so the Learn-More link isn't off center
Differential Revision: https://phabricator.services.mozilla.com/D174110
This patch adds support only for BLOCK permissions because ALLOW permissions
are double-keyed and will be included via a subsequent patch.
Support for a global BLOCK permission is not added here because of
inconsistencies in the way this interacts with device-specific ALLOW
permissions.
Differential Revision: https://phabricator.services.mozilla.com/D170303
It turns out the detect-only pref must be unset for cookie banner
handling to actually work, and while the onboarding doorhanger does
disable this pref, the about:preferences checkbox does not. This patch
corrects the issue, disabling the detect-only pref when the checkbox is
checked, so that users who discover the feature in about:preferences can
successfully enable it.
Differential Revision: https://phabricator.services.mozilla.com/D169645
We need the .learnMore class here, otherwise the "Learn more" link does
not move to a new line, which is the current behavior.
Differential Revision: https://phabricator.services.mozilla.com/D167419
