We don't want to regenerate a backup if scheduled backups are disabled, so
we now do a check inside of the DeferredTask for the scheduling pref before
attempting a regeneration.
The prior patches in this stack cause us to attempt to delete any known
backups when doing certain clearing operations. If a backup destination
folder was not configured or is pointing at a non-existant directory,
this can cause us to throw. This is non-fatal but annoying.
This patch is some belt-and-suspenders which changes the behaviour so that:
1. Deletion is not attempted if scheduled backups are not enabled.
2. The backup destination pref is checked for non-empty values before
attempting to check its existence.
3. The existence check is wrapped in a try/catch in the event that
the destination pref is set to an invalid path for the OS.
Differential Revision: https://phabricator.services.mozilla.com/D221478
This also reorganizes things a bit in BackupService so that uninitBackupScheduler
also disarms the debouncer and any queued debounced jobs end up being inert.
Differential Revision: https://phabricator.services.mozilla.com/D218877
This also reorganizes things a bit in BackupService so that uninitBackupScheduler
also disarms the debouncer and any queued debounced jobs end up being inert.
Differential Revision: https://phabricator.services.mozilla.com/D218877
This is a BackupManifest schema change that will break recovering from
any backups created before this change. However, considering that we
haven't released this feature yet, I figured it wasn't worth the
effort of doing a schema version bump or handling of the prior
version.
I'm making the field optional in the BackupManifest because in the
event that we decide to backport the backup component to ESR 115,
we need to handle the fact that ESR 115 has no notion of a profile
group ID (and is unlikely to ever have such a notion).
Differential Revision: https://phabricator.services.mozilla.com/D218976
Currently, clicking "confirm" buttons on modals in the profile backup settings menu will always close the modals regardless of whether the operation succeeded or failed. In the case of errors, users don't know that something went wrong. It's better to keep the modals open and display an error so that the user knows what to do next and can try to fix the issue, if applicable.
Differential Revision: https://phabricator.services.mozilla.com/D218358
Currently, clicking "confirm" buttons on modals in the profile backup settings menu will always close the modals regardless of whether the operation succeeded or failed. In the case of errors, users don't know that something went wrong. It's better to keep the modals open and display an error so that the user knows what to do next and can try to fix the issue, if applicable.
Differential Revision: https://phabricator.services.mozilla.com/D218358
This allows us to avoid creating a backup while we're in the middle of deleting
one, and deleting a backup when we're in the middle of creating one.
An AbortController is used to clear the lock's request queue on shutdown
in the (unlikely) event that a whole slew of backup creation and deletion
requests have queued up.
Differential Revision: https://phabricator.services.mozilla.com/D218240
Measure final backup archive size to nearest mebibyte in order to understand how much disk space we are using on users' computers in order to back up their data
Differential Revision: https://phabricator.services.mozilla.com/D216708
- Adds a #recoveryInProgress member to BackupService to limit to one recovery at a time
- Adds recoveryInProgress and recoveryErrorCode properties to the BackupSettings component
- Has BackupUIChild set recoveryInProgress / recoveryErrorCode while a recovery is underway.
- Keeps the restore dialog open while the recovery is underway, disables the confirm button and updates it's text to "Restoring..."
- Has BackupUIChild close the recovery dialog if recovery is successful.
Figma: https://www.figma.com/design/vNbX4c0ws0L1qr0mxpKvsW/Fx-Backup?node-id=147-4568&t=rmWErO2I6lpY3Vz7-0
Differential Revision: https://phabricator.services.mozilla.com/D215677
- Adds a #recoveryInProgress member to BackupService to limit to one recovery at a time
- Adds recoveryInProgress and recoveryErrorCode properties to the BackupSettings component
- Has BackupUIChild set recoveryInProgress / recoveryErrorCode while a recovery is underway.
- Keeps the restore dialog open while the recovery is underway, disables the confirm button and updates it's text to "Restoring..."
- Has BackupUIChild close the recovery dialog if recovery is successful.
Figma: https://www.figma.com/design/vNbX4c0ws0L1qr0mxpKvsW/Fx-Backup?node-id=147-4568&t=rmWErO2I6lpY3Vz7-0
Differential Revision: https://phabricator.services.mozilla.com/D215677
This also adds a fake nsIOSKeyStore implementation for our xpcshell tests. This
should allow us to run these tests on apple_silicon in automation.
Differential Revision: https://phabricator.services.mozilla.com/D215707
This exposes some UI to show the most recent backup timestamp
and location (if a recent backup exists), and buttons to show
that location, and to edit the location.
Differential Revision: https://phabricator.services.mozilla.com/D215543
Some of the Firefox profile backup code is executed within a web worker, so errors thrown in the worker do not automatically maintain their full context when caught in the main process.
This change creates a BackupError for throwing errors with causes specific to Firefox profile backup. The new error type is configured to work with the PromiseWorker machinery in the Firefox codebase in order to serialize and deserialize error details across the worker boundary.
Differential Revision: https://phabricator.services.mozilla.com/D215920
Clean up intermediate artifacts in order to be kind to users' disk space:
- remove staging folder after compressing the staging folder into a new single ZIP file
- remove that single ZIP file after embedding its contents into the backup HTML file
Differential Revision: https://phabricator.services.mozilla.com/D215542
