Open
Bug 1092722
Opened 9 years ago
Updated 6 months ago
Sync messes up bookmarks when using multiple devices after rearrangement
Categories
(Firefox :: Sync, defect, P3)
Firefox
Sync
Tracking
()
People
(Reporter: danielstefanmader, Unassigned)
References
Details
(Whiteboard: [sync:bookmarks][sync:rigor])
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 Build ID: 20140923175406 Steps to reproduce: I am using Firefox Sync on four desktop devices plus one mobile device. From these, three devices are used on an almost daily basis: at home PC (Linux), at work (Windows), and my Android phone. All versions are latest Firefox. I have an extensive set of bookmarks, well arranged in folders and subfolders, and sorted manually, including separators. Every few weeks, I do some major changes to the bookmarks, such as reordering them, creating new folders, moving bookmarks, deleting entire folders, etc. Actual results: The sync works OK on the devices used on a daily basis: sometimes duplicate separators remain, or deleted folders are left over. On the other two devices, which I use only every two weeks, or even less than that, the sync messes up the old set with the new changes, creating duplicates, changing ordering, etc. This makes the sync very annoying because I need to do a lot of clean-ups then. Expected results: The sync should have compared the sets based on timestamps and always sync to the latest successful syncs. In case of too many changes or an inconsistent or too different sets, the sync should offer to change the local bookmarks to the server state entirely, or the other way round, or to merge.
Comment 1•8 years ago
|
||
I'm afraid Sync doesn't support some of the fine-grained controls you might want, like directional resets and detection of large changes. Bookmark sync can be flaky. There are lots of moving parts.
Status: UNCONFIRMED → NEW
Component: Server: Sync → Firefox Sync: Backend
Ever confirmed: true
Whiteboard: [sync:bookmarks][sync:rigor]
Comment 2•6 years ago
|
||
We've discussed providing UI for resolving conflicts before. Ryan, didn't you have some designs for this?
Flags: needinfo?(rfeeley)
Comment 3•6 years ago
|
||
We had talked about presenting the user with some kind of merge conflict avoidance choice, but I'm struggling to see how we can avoid creating a foot gun here. I had also heard talk of storing the tombstone records locally indefinitely, which might help in this case too. The less UI we present to the user the better. Can more active devices be given precedence when collections collide?
Flags: needinfo?(rfeeley) → needinfo?(kit)
Comment 4•6 years ago
|
||
I think that's part of the issue: after a node reassignment, we lose all information about which devices are more active. The first device to sync wins, and fast-forwards the server last modified time. As far as the other devices are concerned, that device now has the newest records. The other part is, the more time passes between syncs, the less likely it is that the inactive device's local changes will be reconciled correctly. I think the situation has improved since this bug was filed, but we know there are cases where we'll still do the wrong thing. Making syncs undoable might be another way to avoid this, but we're a long way out from that. We'll talk about what we can do to mitigate at today's triage.
Flags: needinfo?(kit)
Updated•6 years ago
|
Priority: -- → P3
Assignee | ||
Updated•5 years ago
|
Component: Firefox Sync: Backend → Sync
Product: Cloud Services → Firefox
Updated•6 months ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•