Closed
Bug 1392758
Opened 7 years ago
Closed 7 years ago
When Disconnecting Firefox Account, buffer bookmarks are removed from device
Categories
(Firefox for iOS :: Sync, enhancement, P2)
Tracking
()
RESOLVED
WONTFIX
Tracking | Status | |
---|---|---|
fxios | 10.0 | --- |
People
(Reporter: adavis, Unassigned)
References
Details
(Whiteboard: [sync])
While testing bi-directional bookmarks, we realized that when you disconnect your account, we delete all your local bookmarks from your device. Only your bookmarks and nothing else.
If our intention is to delete data after a disconnect, we need to delete EVERYTHING. Not just bookmarks.
If our decision is to leave everything on the device then we need to make sure we don't delete all the bookmarks.
This bug touches a topic related to some other bugs like
Bug 1162778
Bug 1325271
I believe the proposal from Bug 1162778 is the correct way to go. We should ask users what desired behavior they would like.
I don't want to flag these as duplicate yet because the behavior of bookmarks here needs to be documented and addressed.
Comment 1•7 years ago
|
||
For more context, Richard mentioned this behaviour in his notes in https://groups.google.com/a/mozilla.com/d/msg/sync-staff/1OCDVWoK2Xk/hY6GkGgGBgAJ
Comment 2•7 years ago
|
||
In short: this is the tradeoff made in order to upload bookmarks without actually syncing. It's not an intentional experience, but it's also exactly as expected. Most users don't ever sign out of their accounts.
Copying and pasting my email response:
---
There are three different 'places' that a bookmark can be.
It can be local, which means it was just created on the device and wasn't synced yet. That's the state for all users' iOS bookmarks right now.
It can be in the buffer, which means it was downloaded from the server, but it hasn't been merged yet. The buffer can be completely full of junk — it's not consistent, can be a partial read, etc. That's "Desktop Bookmarks" right now.
Or it can be in the mirror, which is a shared, complete bookmark tree that represents a point in time shared with the server.
Full bidirectional sync takes records from the buffer, and new local records, and compares them to the tree in the mirror to build a complete tree. After a sync all records live in the mirror and the buffer and local are empty.
What we've built, and that you tested today, is not full bidirectional sync. What this code does is:
- When you add a new bookmark locally, we directly add it to the server and the buffer.
- When you delete something that's in the buffer, we queue the deletion to send to the server.
- We show both the buffer and local smushed together in the bookmarks UI.
The mirror stays empty, and we're not actually "syncing" anything. It's exactly as if you'd created that iOS bookmark on another device instead.
The buffer is wiped when you sign out (and in some other situations, but I won't get into those): when you sign in to a different account, or go to a different server, it'll be filled up by a different set of bookmarks, and we need to make sure it's clean so that data doesn't accidentally transfer between accounts. If you sign in to the same account again, the same set of bookmarks will be downloaded.
You can try this in release Firefox for iOS: add some local bookmarks and sign in to Sync. You'll see desktop bookmarks in Desktop Bookmarks. Sign out, and they'll disappear.
The situation I described, and that you're asking about here, is a consequence of this quick hack interacting with the semantics of a buffer. You'll see the expected behavior when we're confident enough to flip the switch to turn on proper syncing, and everything ends up in the mirror instead.
Updated•7 years ago
|
Component: Firefox Accounts → Sync
Hardware: Other → All
Summary: When Disconnecting Firefox Account, Bookmarks are Removed from Device but The Rest of Sync Data Remains → When Disconnecting Firefox Account, buffer bookmarks are removed from device
Updated•7 years ago
|
Whiteboard: [sync][fxa] → [sync]
Comment 3•7 years ago
|
||
Alex, a couple questions came out of triage today:
1. What is the expected behavior in desktop when signing out?
2. What should our behavior that we shoot for as a target in v10 be? (i.e., should we prompt the user asking if they want to wipe bookmarks when signing out)
Comment 4•7 years ago
|
||
(In reply to Justin D'Arcangelo [:justindarc] from comment #3)
> 1. What is the expected behavior in desktop when signing out?
Currently all data is left on the device. See the bugs in Comment 0 for discussion on alternatives.
> 2. What should our behavior that we shoot for as a target in v10 be? (i.e.,
> should we prompt the user asking if they want to wipe bookmarks when signing
> out)
I don't think there's much point in prompting if there's no alternative behavior. What choices can we offer?
Leave the bookmarks in the buffer to get trampled if they sign in again? (They won't be uploaded.)
Write a fair amount of code to extract a subtree and try to move it to local? Again, that won't work correctly with the uploader.
Just prompt them -- "sorry, if you sign out you won't have your bookmarks"?
My proposed course of action:
1. Do nothing right now. Very few users sign out of Sync. If they sign back in, their data comes back. Users on iOS _already_ have their desktop bookmarks disappear if they sign out, and that's been the case for two years. Nobody has noticed.
The only way this is data loss is if they have no other devices connected to Sync, open FxA settings, and uncheck "bookmarks".
2. With lots and lots of desktop fixes already done, atomic uploads, a good desktop tracker, buffered application on Android, in-progress tree merging on desktop, and a repair process, we should be approaching the point where we can turn on proper syncing, which skips over this whole discussion.
Reporter | ||
Comment 5•7 years ago
|
||
I think Richard covered everything. I think the most important bit is that users don't seem to logout much so until we land a more official bi-directional, I think this behavior will due.
Flags: needinfo?(adavis)
Reporter | ||
Comment 6•7 years ago
|
||
Closing this for now since we don't seem to plan to fix this.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•