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
This test can be run via:
./mach marionette-test browser/components/backup/test/marionette/test_backup.py
This also makes it so that BackupResource.copySqliteDatabases does not throw if
one of the passed in database files doesn't exist - it'll just ignore it and
move on. This required me to update some tests in order to create some fake
SQLite databases to ensure that the fake Sqlite connection was made and the
backup stub was called for the SQLite databases being copied.
Finally, this also fixes something I noticed - some of our BackupResource's
weren't returning null or objects as their ManifestEntry. This fixes that
and adds tests to cover that case.
Differential Revision: https://phabricator.services.mozilla.com/D207811
- Adds a static `priority` getter in BackupResource base class, which defaults to 0.
- Determine the order resources will be backed up sorted on that priority in `createBackup`, defaulting to unordered.
- Sets `PlacesBackupResource` position 1 so it will run first.
Differential Revision: https://phabricator.services.mozilla.com/D207934
Implements `PlacesBackupResource.backup` to store a copy of `places.sqlite` and `favicons.sqlite` in the staging folder.
If users don't want history remembered or use permanent private browsing mode, we will backup bookmarks instead to a file called `bookmarks.json`. Automatic backup is not yet implemented, so to test changes locally, go to `chrome://browser/content/backup/debug.html` to view where we store the staging folder and to manually run the backup methods for all available backup resources.
Backup files for `PlacesBackupResource` should be under the `places` subfolder in the staging folder.
Differential Revision: https://phabricator.services.mozilla.com/D206532
