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:preferences
using theClear History
button - 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•10 months ago
|
Assignee | ||
Updated•9 months ago
|
Assignee | ||
Updated•7 months ago
|
Assignee | ||
Comment 1•7 months 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•6 months 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•6 months ago
|
Assignee | ||
Comment 3•6 months ago
|
||
This debounces backup regenerations using a DeferredTask.
Assignee | ||
Comment 4•6 months ago
|
||
Assignee | ||
Comment 5•6 months ago
|
||
Assignee | ||
Comment 6•6 months ago
|
||
Assignee | ||
Comment 7•6 months ago
|
||
Assignee | ||
Comment 8•6 months 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•6 months ago
|
||
Assignee | ||
Comment 10•6 months ago
|
||
Assignee | ||
Comment 11•6 months ago
|
||
Assignee | ||
Comment 12•6 months ago
|
||
Updated•6 months ago
|
Updated•6 months ago
|
Updated•6 months ago
|
Updated•6 months ago
|
Updated•6 months ago
|
Updated•6 months ago
|
Updated•6 months ago
|
Comment 13•5 months ago
|
||
Comment 14•5 months 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•5 months 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•4 months ago
|
Comment 16•4 months ago
|
||
Comment 17•4 months 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•4 months ago
|
Description
•