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 involves opening the shadow root of the migration wizard, as the panel-list
really isn't designed to handle being embedded within a closed shadow root.
Differential Revision: https://phabricator.services.mozilla.com/D182484
This involves opening the shadow root of the migration wizard, as the panel-list
really isn't designed to handle being embedded within a closed shadow root.
Differential Revision: https://phabricator.services.mozilla.com/D182484
This involves opening the shadow root of the migration wizard, as the panel-list
really isn't designed to handle being embedded within a closed shadow root.
Differential Revision: https://phabricator.services.mozilla.com/D182484
This involves opening the shadow root of the migration wizard, as the panel-list
really isn't designed to handle being embedded within a closed shadow root.
Differential Revision: https://phabricator.services.mozilla.com/D182484
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 patch was generated as follows:
Run:
`./mach esmify --imports . --prefix=toolkit/mozapps/extensions/AddonManager`
In the output there are linter/prettifier errors due to unused
XPCOMUtils or separate importESModule calls. These have been fixed
manually and verified with `./mach lint --outgoing`.
The `esmify` script also inserts many unwanted newlines around imports
that are broken on two lines due to length. Due to the number of these,
I fixed them programatically.
1. Create patch from the changes so far.
2. From the patch, delete all lines that consist of "+" (i.e. added blank line).
3. Reset the working dir and apply the revised patch.
4. Verify that the diff between step 1 and 3 looks reasonable.
5. Verify that this patch as a whole looks reasonable.
Commands:
```
git diff > rename.diff
:%g/^+$/d
git commit -va -m WIP-rename
git revert HEAD
git apply --recount rename.diff
git diff HEAD^ # and verify that the removed lines are ok.
git commit -va # one last review to verify correctness of whole patch.
git rebase -i HEAD~3 # drop the WIP + reverted commit, pick only the last.
```
`git apply` has the `--recount` option to force it to ignore mismatches
in line counts, which happens because we deleted added lines (^+$)
without fixing up the line counts in the file headers.
Differential Revision: https://phabricator.services.mozilla.com/D179874
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
When an element is re-translated, the textContent is currently dropped.
To avoid that, make it an explicit part of the message.
This requires changing the l10n message ID.
Ideally, the message ID wouldn't change, but that is not possible until
the content can be preserved as a feature, i.e.
https://github.com/projectfluent/fluent.js/issues/169
Differential Revision: https://phabricator.services.mozilla.com/D179323
When an element is re-translated, the textContent is currently dropped.
To avoid that, make it an explicit part of the message.
This requires changing the l10n message ID.
Ideally, the message ID wouldn't change, but that is not possible until
the content can be preserved as a feature, i.e.
https://github.com/projectfluent/fluent.js/issues/169
Differential Revision: https://phabricator.services.mozilla.com/D179323
