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
There are 3 types of changes in this commit:
- from `loadURI(foo.spec)` to `loadURI(foo)`, as there's already a URI
- from `loadURI("string")` to `loadURI(Services.io.newURI("string"))` as the URL is hardcoded
- one or two where there is perhaps an intermediate variable but the patch
context should still make it trivial to ascertain the change is correct.
Depends on D168393
Differential Revision: https://phabricator.services.mozilla.com/D168394
There are 3 types of changes in this commit:
- from `loadURI(foo.spec)` to `loadURI(foo)`, as there's already a URI
- from `loadURI("string")` to `loadURI(Services.io.newURI("string"))` as the URL is hardcoded
- one or two where there is perhaps an intermediate variable but the patch
context should still make it trivial to ascertain the change is correct.
Depends on D168393
Differential Revision: https://phabricator.services.mozilla.com/D168394
When these panels had arrows, I guess the bottomcenter topleft alignment
made sense so that you could precisely align the arrow, but that's not
what we do now.
Don't use bottomcenter / leftcenter / rightcenter, since we really want
the sides to align.
This shouldn't change behavior on any platform except Linux + Wayland,
where the alignment looks good now in the case of bug 1784876.
Differential Revision: https://phabricator.services.mozilla.com/D156099
When these panels had arrows, I guess the bottomcenter topleft alignment
made sense so that you could precisely align the arrow, but that's not
what we do now.
Don't use bottomcenter / leftcenter / rightcenter, since we really want
the sides to align.
This shouldn't change behavior on any platform except Linux + Wayland,
where the alignment looks good now in the case of bug 1784876.
Differential Revision: https://phabricator.services.mozilla.com/D156099
It does the same as window.devicePixelRatio. However a bunch of this
code is copy-pasted code trying to scale a canvas, but not messing with
full zoom is the right thing to do.
The full zoom value in the top level browser.xhtml page is always 1
anyways, and WindowsPreviewPerTab looking at the current browser tab's
full zoom is just bizarre...
Differential Revision: https://phabricator.services.mozilla.com/D138020
This also causes nssFailure2 network errors to be treated as certificate errors
in the identity block, and adjusts tests for this new reality. It also readds
a test to test a non-cert-related network error to ensure that case doesn't
lose coverage.
Differential Revision: https://phabricator.services.mozilla.com/D121176
This also causes nssFailure2 network errors to be treated as certificate errors
in the identity block, and adjusts tests for this new reality. It also readds
a test to test a non-cert-related network error to ensure that case doesn't
lose coverage.
Differential Revision: https://phabricator.services.mozilla.com/D121176
