User Agent: Mozilla/5.0 (Windows NT 6.1; rv:46.0) Gecko/20100101 Firefox/46.0 Build ID: 20160502172042 Firefox for Android Steps to reproduce: 1. Have Firefox on PC and on Android synced. 2. Have sorted the PC bookmark folders and bookmarks. 3. Add a bookmark on Android. 4. Make sure that the bookmarks are synced again. Actual results: The bookmark folders and the bookmarks in the folders on the PC are scrambled (the sequence is different than they were sorted before). Expected results: The sequence should not change.
Component: Untriaged → Bookmarks & History
OS: Unspecified → Android
Component: Sync → Firefox Sync: Cross-client
Product: Firefox → Cloud Services
Version: 46 Branch → unspecified
Component: Firefox Sync: Cross-client → Android Sync
Product: Cloud Services → Android Background Services
This is, sadly, well known (if not well understood). Firefox for Android will _force_ an order when it finds inconsistent data. That can be due to inconsistent data on the server (generally, this is due to Desktop tracking bugs) or due to client issues on the Android side (generally, due to connectivity issues). It may be that the ongoing work to improve the Desktop Sync client has shifted the majority of the problems to the Android side. grisha's work on Bug 730142 and friends should help here. rnewman: considering duping this ticket.
Status: UNCONFIRMED → NEW
Depends on: 730142
Ever confirmed: true
(In reply to Nick Alexander :nalexander (leave until January 2017) from comment #1) > This is, sadly, well known (if not well understood). Firefox for Android > will _force_ an order when it finds inconsistent data. Could you tell me more about this, please? How does Fennec determine the order when records are missing?
See Also: → bug 1314103
Other related work on Android that might help with this: Bug 1291821, Bug 1253111. Desktop side of things: Bug 1305563, Bug 1294599, and various others.
(In reply to Kit Cambridge [:kitcambridge] from comment #2) > (In reply to Nick Alexander :nalexander (leave until January 2017) from > comment #1) > > This is, sadly, well known (if not well understood). Firefox for Android > > will _force_ an order when it finds inconsistent data. > > Could you tell me more about this, please? How does Fennec determine the > order when records are missing? Short answer: Fennec implementation specific approach that moves some things into "unsorted bookmarks" and tries to patch up the resulting tree. rnewman can give details. It's magic, but not that deep.
Bug 814801 Comment 0 summarizes what's happening. Both desktop and Android apply incoming records to canonical storage as they're downloaded. If an Android device sees a partial server state -- for example, it sees Bookmark B but not its parent Folder A -- it'll do just what desktop does: put Bookmark B into Unsorted Bookmarks. Historically (perhaps no longer the case with the recent tracker changes -- this bug might be introduced on desktop, too!), desktop doesn't track this re-filing as a change. Android does. If Folder A arrives before the end of that first sync, both platforms are fine: Bookmark B will be moved into the correct folder. If the downloading device is interrupted, we're also fine: we'll re-download all those records again. If Folder B doesn't arrive, but the sync finishes, we're kinda screwed. Desktop _might_ upload Unsorted Bookmarks (if there's a local change, it will), indicating that Bookmark B is a child. The server will then be inconsistent (B->A, but Unsorted.children contains B), and you'll see this bug Desktop might not, in which case the desktop will have diverged from the server (B is in Unsorted locally, and in A on the server). Desktop will perhaps corrupt the server later, as soon as a write touches one of those records. Android _always_ makes a local consistent state, and it _always_ makes sure the server matches. So when it temporarily reparents B, it marks B and Unsorted Bookmarks as changed. At the end of the sync, it'll make the server match the structure it has locally. That's all well and good, if the server really was corrupt. But in some cases another desktop missed a change, or was interrupted, and left a partial write on the server. It'll later come to sync, will download Android's uploaded changes, and will apply them. Of course, the server record for partial folders will be a scrambled subset, and Places will itself come up with some order. Visible corruption. All the usual solutions improve this: * Atomic uploads reduce the likelihood of seeing partial state. * Two-phase record application reduces the need to chew up local folders for temporary storage. * Tracker fixes on desktop reduce the need for Android to fix things, and thus reduces the likelihood of a bad fix.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1291821
You need to log in before you can comment on or make changes to this bug.