Open Bug 1092722 Opened 8 years ago Updated 4 years ago

Sync messes up bookmarks when using multiple devices after rearrangement

Categories

(Firefox :: Sync, defect, P3)

defect

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.
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]
Blocks: 621584
We've discussed providing UI for resolving conflicts before. Ryan, didn't you have some designs for this?
Flags: needinfo?(rfeeley)
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)
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)
Priority: -- → P3
Component: Firefox Sync: Backend → Sync
Product: Cloud Services → Firefox
You need to log in before you can comment on or make changes to this bug.