Hi folks, Figured I'd send a note to a wide distribution.
We have preliminary bookmark telemetry from iOS clients in the wild. This is the first time we've been able to measure the health of users' bookmark collections: whether or not all of their bookmarks have made it to their Firefox Account, with every folder's children present, and every record's parent folder present and correct. Caveats apply: - We only sampled 63 users. Our pre-release channel is small. - These users opted in to testing pre-release Firefox on iOS, so they probably skew slightly more towards heavier bookmark usage. - We haven't tracked characteristics of their Sync account, so these accounts might be old and crufty or new and shiny. Probably they don't heavily overlap with Android users, at least. - We haven't tracked how many devices these users are syncing, but it must be at least one iOS and one non-iOS device, probably a desktop. We're taking a measurement at each point at which the user's device would attempt to bidirectionally sync bookmarks. That means every fifteen minutes or on launch for failing users, and for everyone else only when a bookmark changes somewhere. We're also tracking *why* the user's bookmark collection is considered inconsistent, which is interesting to me and MarkH, but probably not for anyone else! Our results: - These 63 users averaged 827 bookmarks apiece. Min = 0, Max = 6234, Median = 491. - 20 users have bookmark data that isn't correct. Only *one user recovered* on a subsequent attempt. - - Above 0 bookmarks, your chance of your server data being correct is 68%. - *Above 222 bookmarks, your chance is 50-50*. - Above 1000 bookmarks (25% of this sample population), your chance is just 37%. My conclusion: the state of users' bookmark collections on the server, as uploaded by desktop, is as bad as I had feared: if we enable bidirectional bookmark sync now, a moderate user has a 50-50 chance of being in a good state and being able to sync. (Note that whether you encounter problems is decided by your behavior more than circumstance — if you don't, e.g., re-file bookmarks into folders, and don't bookmark in close succession, then you might make it to 20K without problems!) It's worth noting that *this issue does not only impact iOS*. Those same users, connecting an Android device or a desktop, have about that chance of seeing bookmarks reordered, duplicated, or moved — Bug 621584. That these issues are so widespread implies that there are multiple causes, and that partial writes (Bug 1253051) are not solely responsible. My money is on missed changes (Bug 1235269); the number of parentid mismatches and structure collisions support this hypothesis. That one of the failing clients subsequently reached consistency implies that partial reads or writes do occur in the wild, and that the iOS client *does correctly recover* if the records eventually make it to the server. That's a nice positive finding. Our goal should be to make sure that the only inconsistencies a client sees are due to partial reads, which is a natural and expected temporary state. My recommendations continue to be in line with conversations I've had with many of you: - Prioritize two pieces of desktop work: *recovery* and *correct tracking*. It's not enough to just fix tracking; in order to unblock existing users we also need to proactively detect and fix up server contents to match the client's data. Both of these items are under the umbrella of Bug 1235269, but we should split out recovery and act on that, and correctly implement tracking of changes alongside. - Work on atomic uploads to avoid partial writes. This is a little bit of a project; the server folks are rolling this out, then clients need to opt in to the behavior. It's less important for desktop than change tracking, but it still needs to get done. My tentative proposal for iOS is to* ship 3.0 as-is*, enabling bidirectional sync in 4.0 or 5.0 — as soon as we're confident that desktops will eventually self-recover and our current 50-50 bias will trend towards 100%. I think this is acceptable; we'll continue to offer the read-only fallback. The alternative is that we ship 3.0 with the flag flipped, and approximately *70%* of our users get bidirectional syncing, with some of those users' Firefoxes eventually stopping as they encounter fresh corruption. That number is lower than I feel comfortable with for a feature that changes how your bookmark UI behaves. Opinions, questions, clarifications, etc. are all most welcome!
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
