Do not isolate `https-only-load-insecure` by origin attributes. This way the HTTPS-Only exceptions will behave similar to the `cookie` permission. This means that exceptions set in the system settings will also apply to private windows, but exceptions set in private windows via the identity pane will be reset after closing the browser.
Depends on D182761
Differential Revision: https://phabricator.services.mozilla.com/D183745
- Update the HTTPS-Only dropdown in the site identity pane to always set exceptions for the http version of the current origin.
- Add new parameter `forcedHTTP` to `gPermissionManager`, in order to only allow origins with a http scheme to be added in the HTTPS-Only section of the settings. This means when a https URL is added as an exeption, it will automatically be converted into a http one.
- Add a migration to convert all existing HTTPS-Only exceptions with a https scheme to a http scheme.
- Update `browser_https_only_exceptions.js` and `browser_identityPopup_HttpsOnlyMode.js` to account for this new behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D182761
This should be seen as a temporary change since the UI probably needs a slightly bigger update if it should manage both HTTPS-Only and HTTPS-First.
Depends on D179424
Differential Revision: https://phabricator.services.mozilla.com/D179425
This should fix the issue experienced by the reporter. It also pushes the
re-entrancy guard into the the 'init' method we define on gCategoryInits
objects, and removes the asynchronicity which was only there for fluent's sake.
Instead of blocking the insertion on fluent, which meant that for the in-page
find functionality we do N initializations and fluent passes, we make each of
the 2 consumers responsible for checking translation has completed. This means
find in page now just has 1 fluent pass, instead of N passes for N categories.
This should speed up the find in page initialization, and means initialization
of a category is now sync instead of async.
Differential Revision: https://phabricator.services.mozilla.com/D178232
This should fix the issue experienced by the reporter. It also pushes the
re-entrancy guard into the the 'init' method we define on gCategoryInits
objects, and removes the asynchronicity which was only there for fluent's sake.
Instead of blocking the insertion on fluent, which meant that for the in-page
find functionality we do N initializations and fluent passes, we make each of
the 2 consumers responsible for checking translation has completed. This means
find in page now just has 1 fluent pass, instead of N passes for N categories.
This should speed up the find in page initialization, and means initialization
of a category is now sync instead of async.
Differential Revision: https://phabricator.services.mozilla.com/D178232
This should fix the issue experienced by the reporter. It also pushes the
re-entrancy guard into the the 'init' method we define on gCategoryInits
objects, and removes the asynchronicity which was only there for fluent's sake.
Instead of blocking the insertion on fluent, which meant that for the in-page
find functionality we do N initializations and fluent passes, we make each of
the 2 consumers responsible for checking translation has completed. This means
find in page now just has 1 fluent pass, instead of N passes for N categories.
This should speed up the find in page initialization, and means initialization
of a category is now sync instead of async.
Differential Revision: https://phabricator.services.mozilla.com/D178232
This should fix the issue experienced by the reporter. It also pushes the
re-entrancy guard into the the 'init' method we define on gCategoryInits
objects, and removes the asynchronicity which was only there for fluent's sake.
Instead of blocking the insertion on fluent, which meant that for the in-page
find functionality we do N initializations and fluent passes, we make each of
the 2 consumers responsible for checking translation has completed. This means
find in page now just has 1 fluent pass, instead of N passes for N categories.
This should speed up the find in page initialization, and means initialization
of a category is now sync instead of async.
Differential Revision: https://phabricator.services.mozilla.com/D178232
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
For speaker permissions, this has the effect of presenting a menulist instead
of a label when a device-specific ALLOW permission is set, providing the
option to the user of changing this to a BLOCK.
A global permission for speaker selection is not currently supported but if it
were implemented and set to BLOCK, then a menulist would be shown for all
sites with permissions set. It would include at least PROMPT and BLOCK
menuitems. This change would mean that the menulist selected item can display
"Allowed" when a device-specific ALLOW permission has already been granted
through a selectAudioOutput() prompt.
_permissionsToChange is modified in _removePermissionFromList() so that
permissions changed then deleted are not added by onApplyChanges().
Differential Revision: https://phabricator.services.mozilla.com/D172085
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
