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
This class will be used to generate the keys and ephemera necessary to
encrypt backups. The actual encryption will occur in a later patch.
The state can be serialized and deserialized to disk.
Differential Revision: https://phabricator.services.mozilla.com/D210718
This class will be used to generate the keys and ephemera necessary to
encrypt backups. The actual encryption will occur in a later patch.
The state can be serialized and deserialized to disk.
Differential Revision: https://phabricator.services.mozilla.com/D210718
Move style persistence from XULstore to SessionStore.
Follow up bug to fix persistence of sidebar when only a new tab is open and window is closed, and its
accompanying test `browser_sidebar_persist.js`: Bug 1898613
Depends on D207048
Differential Revision: https://phabricator.services.mozilla.com/D207787
backup-settings changes:
- adds a new button in the Backup section of about:preferences / about:settings
- shows the turn on dialog after pressing the button
Turn on dialog behaviour (implemented):
- pressing the cancel will close the dialog
- pressing the confirm button will set the pref browser.backup.scheduled.enabled=true and close the dialog
- pressing the passwords checkbox will show more options
Turn on dialog behaviour (not implemented):
- requiring a password for the backup (see Bug 1895981)
- modifying the save location and showing a file picker (see Bug 1895943)
Other changes:
- tests for backup-settings and the turn on dialog
- Storybook template for the turn on dialog
Lo-fi Figma designs: https://www.figma.com/design/vNbX4c0ws0L1qr0mxpKvsW/Fx-Backup?node-id=147-4558&t=PYLY0QMN1n8GR9vW-0
Differential Revision: https://phabricator.services.mozilla.com/D209769
This is an intermediary stage before the compressed archive gets (optionally)
encrypted and written into the container file. This is why there's not a whole
lot of testing for the compressed file - those tests will get added once it
completes its journey into the container file so that we can test both
extraction and decompression at the same time.
Differential Revision: https://phabricator.services.mozilla.com/D210311
This is an intermediary stage before the compressed archive gets (optionally)
encrypted and written into the container file. This is why there's not a whole
lot of testing for the compressed file - those tests will get added once it
completes its journey into the container file so that we can test both
extraction and decompression at the same time.
Differential Revision: https://phabricator.services.mozilla.com/D210311
Data science wants us to copy the client IDs from whichever profile initiated recovery.
For legacy telemetry, the client ID is stored in a datareporting/state.json file.
This patch ensures that the client ID exists in the state.json file in the profile
that initiated recovery before then copying it over into the destination profile
for recovery.
This patch also updates the Marionette test to use a separate user profile to
initiate recovery from to ensure we get a unique client ID for it, compared to
the profile that the backup was created for.
Differential Revision: https://phabricator.services.mozilla.com/D209555
Since we are moving away from XUL for the revamped sidebar, remove persistence off of XULstore.
For now, this involves moving persistence of "sidebar-command" and "positionend" to SessionStore.
A follow up bug 1892033 for moving the style attribute to SessionStore has been filed. This is slightly more involved,
hence the separate patch.
Differential Revision: https://phabricator.services.mozilla.com/D207048
This patch updates test_backup.py to write some testing data into various data stores
that BackupService is backing up, create a backup, recover from that backup, and check
to see if the written data exists in the recovered profile.
This isn't exactly exhaustive - there are a number of data stores that aren't accounted
for here yet. Chiefly AddonsBackupResource and SessionStoreBackupResource (bug 1894004),
but also:
1. FxA sign-in status
2. Logins backups
3. Site Security Service State
4. ProfileAge data
5. WebRTC device ID mappings
6. Favicons
7. XUL Store data
8. Content preferences
9. Containers preferences
10. File handler preferences
11. Search preferences
12. user.js and chrome/ customizations
Still, this is a start, and certainly better than nothing. Bug 1894089 has been filed
to add more data to test the listed 12 items.
Differential Revision: https://phabricator.services.mozilla.com/D208939
This Promise is mainly for use by Marionette tests to know when to check
data stores that might have been updated by postRecovery steps.
Differential Revision: https://phabricator.services.mozilla.com/D208938
