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
The patch adds `password-validation-inputs` into `turn-on-scheduled-backups`, therefore removing the need for duplicate password fields and validation logic in the latter component. The turn-on dialog is notified via a dispatched event whenever a valid and invalid password pair is entered.
Tests are written in D216892
Depends on D216617
Differential Revision: https://phabricator.services.mozilla.com/D216762
- 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
Summary of updates:
- the "sensitive data" checkbox to toggle backup encryption is no longer displayed when a user turns off scheduled backups
- the "Change password" button, which only appears for encrypted backups, is now aligned with the checkbox + description to match the Figma spec
- once scheduled backups are turned off, the latest backup file is deleted via the `BackupService.deleteLastBackup()` method
Tests
- moved browser tests related to the turn-off scheduled backups dialog from `backup_settings.js` to their own file `browser_settings_turn_off_scheduled_backups.js`
- updated some browser tasks testing add/change password to have scheduled backups enabled by default
- added a chrome test for the sensitive data checkbox's visibility whenever scheduled backups are toggled on or off
Depends on https://phabricator.services.mozilla.com/D215543
Differential Revision: https://phabricator.services.mozilla.com/D215826
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
This implements getting the information needed to show the date of a backup in the restore component and showing the password input if that backup is encrypted.
- Adds a `getBackupFileInfo` method to `BackupService` that will call `sampleArchive` for a passed backup file and update the `backupFileInfo` in the state with a subset of that info.
- Update the `GetBackupFileInfo` event handler in `BackupUIParent` to use the new `getBackupFileInfo` method.
Differential Revision: https://phabricator.services.mozilla.com/D214899
This implements getting the information needed to show the date of a backup in the restore component and showing the password input if that backup is encrypted.
- Adds a `getBackupFileInfo` method to `BackupService` that will call `sampleArchive` for a passed backup file and update the `backupFileInfo` in the state with a subset of that info.
- Update the `GetBackupFileInfo` event handler in `BackupUIParent` to use the new `getBackupFileInfo` method.
Differential Revision: https://phabricator.services.mozilla.com/D214899
Since the ArchiveJSONBlock uses a $ref to reference the metadata in the
BackupManifest schema, we have to change the JSON validation mechanism
we're using to one that supports $ref's.
Differential Revision: https://phabricator.services.mozilla.com/D212860
This patch adds a new dialog for disabling a backup's password protection.
Steps to test this feature:
1. First ensure that the following prefs are enabled: browser.backup.enabled and browser.backup.preferences.ui.enabled
2. Then ensure that the existing backup for the current profile has encryption enabled (should have enc-state.json)
3. Else, access the debug page (chrome://browser/content/backup/debug.html) to enable encryption
4. Once encryption is enabled, the sensitive data checkbox should be checked in about:settings / about:preferences
5. Clicking the checked checkbox should now show the new dialog for removing password protection
6. If the dialog is confirmed, the checkbox should be unchecked in both the settings/preferences page and the debug page
Other notes:
- If the checkbox is *not* checked, nothing will happen. This is because the dialog for enabling password protection is not yet implemented
- Added tests and Storybook entries as well
Figma: https://www.figma.com/design/vNbX4c0ws0L1qr0mxpKvsW/Fx-Backup?node-id=147-4568&t=9NNUojWMeOLwe3rD-0
Differential Revision: https://phabricator.services.mozilla.com/D213171
- Adds button in the preferences backup settings to restore from a backup file.
- Adds a dialog component `restore-from-backup` which will open a filepicker to select a HTML backup file to restore from, show the backup's date and prompt to input a password if needed.
- Adds a stub `getBackupInfo` event to eventually return metadata and config JSON from `sampleArchive` in Bug 1901132.
Does not yet implement:
- Expanding the input to fit multiline files names.
- Restoring the selected backup file.
Figma: https://www.figma.com/design/vNbX4c0ws0L1qr0mxpKvsW/Fx-Backup?node-id=147-8701&t=zvoykS3OusX9YVCv-4
Differential Revision: https://phabricator.services.mozilla.com/D211248
Patch by kpatenio <kpatenio@mozilla.com>.
Makes several updates to turn-on-scheduled-backups dialog:
- Selecting the encryption option will disable the Confirm button until matching passwords are entered
- Confirming turn-on options with encryption enabled will call BackupService.enableEncryption
- Does not turn on scheduled backups if there is any issue with enabling encryption.
Differential Revision: https://phabricator.services.mozilla.com/D211945
Patch by kpatenio <kpatenio@mozilla.com>.
1. Allows for selecting a custom path or the default (Documents) path for saving backups. The selection is passed from the "turn-on-scheduled-backups" dialog to "BackupService".
2. After pressing the "Choose" button in the dialog, a filepicker will appear so that a folder can be selected.
3. Once the dialog is confirmed, the absolute path is saved to a pref called "browser.backup.location" and saved in the service state.
Other changes:
- Added the Documents folder as the default save location
- Added an onUpdate function for "browser.backup.location" that passes the updated BackupService state to registered widgets (backup settings section, dialogs)
- Added Storybook entries and tests for the newly updated input and filepicker
Figma: https://www.figma.com/design/vNbX4c0ws0L1qr0mxpKvsW/Fx-Backup?node-id=147-4568&t=tILUMKfg8c6Ed1Ul-0 (turn on backup dialog)
Differential Revision: https://phabricator.services.mozilla.com/D210850
There are a number of interesting things going on this patch that I think are worth highlighting
here for my reviewers:
1. The single-file archive format is an HTML file that uses an inlined multipart/mixed MIME
message within a HTML document comment in order to embed the backup data into the archive.
2. We use the multipart/mixed nsIStreamConverter to extract the JSON and binary data from
the MIME block.
3. We use a Archive Worker to do the archive creation, allowing us to do the work of construction
off of the main thread.
4. The Archive Worker is only parsing the header and getting the byte offset of the MIME block.
Extraction is happening in the parent process. This is mainly for simplicity for now, since
the Archive Worker cannot invoke an nsIStreamConverter. Down the line, if we determine that
we'd prefer the Archive Worker do the base64 decoding off of the main thread, we may need
to use a Message Channel to send the byte sfrom the nsIStreamConverter to it, and add
stream-writing support to IOUtils so that the Archive Worker can take care of sending the
decoded bytes to disk.
5. The patch doesn't expose the extraction mechanism in any way except through the debug
interface right now. That will come down the line. In the meantime, this mechanism
can be manually tested in the debug interface by creating a backup, which should also
create an "archive.html" file in the backups folder. Using the "Extract from archive"
button in the debug tool will let you select that HTML file and extract the ZIP as
a file in the backups folder called "extraction.zip".
6. The test template contains Unicode characters because certain locales might involve
us writing Unicode characters in the HTML template when generating the archive. The
fun part about that is calculating where the byte offset is for the MIME block! See
the comment in the Archive.worker.mjs script for how that works.
Differential Revision: https://phabricator.services.mozilla.com/D211588
Makes several updates to turn-on-scheduled-backups dialog:
- Selecting the encryption option will disable the Confirm button until matching passwords are entered
- Confirming turn-on options with encryption enabled will call BackupService.enableEncryption
- Does not turn on scheduled backups if there is any issue with enabling encryption.
Differential Revision: https://phabricator.services.mozilla.com/D211945
1. Allows for selecting a custom path or the default (Documents) path for saving backups. The selection is passed from the "turn-on-scheduled-backups" dialog to "BackupService".
2. After pressing the "Choose" button in the dialog, a filepicker will appear so that a folder can be selected.
3. Once the dialog is confirmed, the absolute path is saved to a pref called "browser.backup.location" and saved in the service state.
Other changes:
- Added the Documents folder as the default save location
- Added an onUpdate function for "browser.backup.location" that passes the updated BackupService state to registered widgets (backup settings section, dialogs)
- Added Storybook entries and tests for the newly updated input and filepicker
Figma: https://www.figma.com/design/vNbX4c0ws0L1qr0mxpKvsW/Fx-Backup?node-id=147-4568&t=tILUMKfg8c6Ed1Ul-0 (turn on backup dialog)
Differential Revision: https://phabricator.services.mozilla.com/D210850
There are a number of interesting things going on this patch that I think are worth highlighting
here for my reviewers:
1. The single-file archive format is an HTML file that uses an inlined multipart/mixed MIME
message within a HTML document comment in order to embed the backup data into the archive.
2. We use the multipart/mixed nsIStreamConverter to extract the JSON and binary data from
the MIME block.
3. We use a Archive Worker to do the archive creation, allowing us to do the work of construction
off of the main thread.
4. The Archive Worker is only parsing the header and getting the byte offset of the MIME block.
Extraction is happening in the parent process. This is mainly for simplicity for now, since
the Archive Worker cannot invoke an nsIStreamConverter. Down the line, if we determine that
we'd prefer the Archive Worker do the base64 decoding off of the main thread, we may need
to use a Message Channel to send the byte sfrom the nsIStreamConverter to it, and add
stream-writing support to IOUtils so that the Archive Worker can take care of sending the
decoded bytes to disk.
5. The patch doesn't expose the extraction mechanism in any way except through the debug
interface right now. That will come down the line. In the meantime, this mechanism
can be manually tested in the debug interface by creating a backup, which should also
create an "archive.html" file in the backups folder. Using the "Extract from archive"
button in the debug tool will let you select that HTML file and extract the ZIP as
a file in the backups folder called "extraction.zip".
6. The test template contains Unicode characters because certain locales might involve
us writing Unicode characters in the HTML template when generating the archive. The
fun part about that is calculating where the byte offset is for the MIME block! See
the comment in the Archive.worker.mjs script for how that works.
Differential Revision: https://phabricator.services.mozilla.com/D211588
