Update backups when history and bookmarks are modified or manually cleared
Categories
(Firefox :: Profile Backup, task, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox132 | --- | fixed |
People
(Reporter: kpatenio, Assigned: mconley)
References
(Blocks 1 open bug)
Details
(Whiteboard: [fidefe-device-migration])
Attachments
(11 files)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
According to our spec, we want to remake the backup file whenever history and/or bookmarks are modified. We will need to consider the following:
- users can clear history in
about:preferencesusing theClear Historybutton - users can clear recent history using the "Panic"/"Forget" button
- we probably don't want to update the backup at every deletion/insertion; we should determine how often to make the backup in a way that is both reasonable and optimized for performance
Updated•2 years ago
|
| Assignee | ||
Updated•2 years ago
|
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Comment 1•1 year ago
|
||
The spec calls for the following events to clear / recreate the backup for our first version:
- Deleting any history entry (but not the routine aging out of history data)
- Deleting any download history entry (but not the routine aging out of download history data)
- Deleting any bookmark
- Deleting any password
- Uninstalling any add-on
- Clearing site data and cookies for a given site
- Revoking any site permission
- Deleting any saved payment method
- Deleting any saved address
- Dismissing a new tab page shortcut
- Clearing all cookies and site data from about:preferences
- Clearing all site settings from about:preferences
- Clearing all history from about:preferences
| Assignee | ||
Comment 2•1 year ago
|
||
Just a quick update here - I've filed bug 1908002 as a dependency, because I'm hoping to expose Web Locks to the browser UI so that we can use them to make sure that we don't interleave creating backups with deleting them.
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Comment 3•1 year ago
|
||
This debounces backup regenerations using a DeferredTask.
| Assignee | ||
Comment 4•1 year ago
|
||
| Assignee | ||
Comment 5•1 year ago
|
||
| Assignee | ||
Comment 6•1 year ago
|
||
| Assignee | ||
Comment 7•1 year ago
|
||
| Assignee | ||
Comment 8•1 year ago
|
||
This also reorganizes things a bit in BackupService so that uninitBackupScheduler
also disarms the debouncer and any queued debounced jobs end up being inert.
| Assignee | ||
Comment 9•1 year ago
|
||
| Assignee | ||
Comment 10•1 year ago
|
||
| Assignee | ||
Comment 11•1 year ago
|
||
| Assignee | ||
Comment 12•1 year ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 13•1 year ago
|
||
Comment 14•1 year ago
|
||
Backed out for causing failures at LateWriteChecks.cpp.
Backout link: https://hg.mozilla.org/integration/autoland/rev/aebd01ff7b22a3ebf20999a82d21b745a4d382a9
Push where failures started: https://treeherder.mozilla.org/jobs?repo=autoland&selectedTaskRun=IxJBTKCbR-q6KUKGCiNQYg.0&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=6216b4b406a50a5f30f49512e9f5aa0ee75d8202
Failure log: https://treeherder.mozilla.org/logviewer?job_id=472949480&repo=autoland&lineNumber=7876
| Assignee | ||
Comment 15•1 year ago
|
||
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:
- Deletion is not attempted if scheduled backups are not enabled.
- The backup destination pref is checked for non-empty values before
attempting to check its existence. - 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.
Depends on D218880
Updated•1 year ago
|
Comment 16•1 year ago
|
||
Comment 17•1 year ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/f36f2530ac50
https://hg.mozilla.org/mozilla-central/rev/6ee3cddf0d2b
https://hg.mozilla.org/mozilla-central/rev/b322a1ebdee8
https://hg.mozilla.org/mozilla-central/rev/56ba5ff598eb
https://hg.mozilla.org/mozilla-central/rev/d6720b4cc13a
https://hg.mozilla.org/mozilla-central/rev/77ab1568ac86
https://hg.mozilla.org/mozilla-central/rev/2ab4325c3888
https://hg.mozilla.org/mozilla-central/rev/e7893f87be86
https://hg.mozilla.org/mozilla-central/rev/0bfa7b25d260
https://hg.mozilla.org/mozilla-central/rev/7fd07c1a19c7
https://hg.mozilla.org/mozilla-central/rev/96ccbb7f4cfd
| Assignee | ||
Updated•1 year ago
|
Description
•