To ensure Glean is always shut down, the FOG service must be initialized.
To ensure the FOG service is initialized, we cannot rely on BrowserGlue's
_scheduleStartupIdleTasks, since that isn't guaranteed to be called in short,
busy sessions.
So we rely on BrowserGlue's quit-application-granted listener
(which is before AppShutdownConfirmed, which is before XPCOMShutdown) so long
as BrowserGlue was ever init'd.
(We'd rely on __dispose instead, which runs around AppShutdown/profile-before-change,
but init'ing services that late sometimes prompts OOMs in xpchsell)
(This is important for catching early data in short, busy sessions.
In most cases this code shouldn't run)
Differential Revision: https://phabricator.services.mozilla.com/D181541
- 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
To ensure Glean is always shut down, the FOG service must be initialized.
To ensure the FOG service is initialized, we cannot rely on BrowserGlue's
_scheduleStartupIdleTasks, since that isn't guaranteed to be called in short,
busy sessions.
So we rely on BrowserGlue's quit-application-granted listener
(which is before AppShutdownConfirmed, which is before XPCOMShutdown) so long
as BrowserGlue was ever init'd.
(We'd rely on __dispose instead, which runs around AppShutdown/profile-before-change,
but init'ing services that late sometimes prompts OOMs in xpchsell)
(This is important for catching early data in short, busy sessions.
In most cases this code shouldn't run)
Differential Revision: https://phabricator.services.mozilla.com/D181541
Bug 1823537 moved the registration of the MigrationWizard JSWindowActor pair
into MigrationUtils from BrowserGlue. This makes it so that the wizard can
be used properly in the scenario where BrowserGlue hasn't yet had a chance
to run (which is the case when we're showing the migration wizard on startup).
This, however, means that the actors aren't being registered unless MigrationUtils
is loaded, which is no longer the case having moved the registration outside of
BrowserGlue.
This means that the embedded migration wizard in about:welcome (and the spotlight
experience in bug 1837051) will not work until that module loads and the
registration occurs.
Differential Revision: https://phabricator.services.mozilla.com/D180725
Bug 1823537 moved the registration of the MigrationWizard JSWindowActor pair
into MigrationUtils from BrowserGlue. This makes it so that the wizard can
be used properly in the scenario where BrowserGlue hasn't yet had a chance
to run (which is the case when we're showing the migration wizard on startup).
This, however, means that the actors aren't being registered unless MigrationUtils
is loaded, which is no longer the case having moved the registration outside of
BrowserGlue.
This means that the embedded migration wizard in about:welcome (and the spotlight
experience in bug 1837051) will not work until that module loads and the
registration occurs.
Differential Revision: https://phabricator.services.mozilla.com/D180725
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
Safari doesn't let us import all passwords from Keychain at once. Instead,
the user needs to authorize each read from Keychain one by one. This is
not tenable for password import.
Instead, we show the user instructions on how they can export their passwords
from Safari into a CSV file that can then be imported. This patch adds support
for showing those instructions (which had landed earlier in bug 1818789) and
then importing from that CSV file upon selection.
The data-review for the safari_password_file Telemetry event being used here
was done earlier in bug 1824786.
Differential Revision: https://phabricator.services.mozilla.com/D175669
Safari doesn't let us import all passwords from Keychain at once. Instead,
the user needs to authorize each read from Keychain one by one. This is
not tenable for password import.
Instead, we show the user instructions on how they can export their passwords
from Safari into a CSV file that can then be imported. This patch adds support
for showing those instructions (which had landed earlier in bug 1818789) and
then importing from that CSV file upon selection.
The data-review for the safari_password_file Telemetry event being used here
was done earlier in bug 1824786.
Differential Revision: https://phabricator.services.mozilla.com/D175669
