Closed Bug 976594 Opened 11 years ago Closed 9 years ago

FxA based Sync can easily result in data loss

Categories

(Firefox :: Sync, defect, P2)

29 Branch
x86
macOS
defect

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: soeren.hentzschel, Unassigned)

Details

Attachments

(1 file)

Hi, the new FxA based sync can easily result in data loss. I moved a few open tabs to my bookmarks toolbar and didn't notice that I was no more logged in (how would I know that without opening the Australis menu and looking at the bottom of the menu every time I start Firefox? Sometimes I am logged in, sometimes not…). So I entered my password and a few seconds later my last added bookmarks were lost and already deleted bookmarks reappeared. In all the years I had never a data loss issue with Sync. In my opinion the user has to be protected against data loss, currently it's too easy to lose important data.
Blocks: 969593
Could you provide detailed numbered steps to reproduce this? Thanks.
STR: 1. sign in to FxA / Sync 2. create bookmarks and so on 3. sometimes it happens that you need to log in again, I don't know why or when that happens. 4. if you are no longer signed in create new bookmarks and / or delete existing bookmarks. 5. log in to FxA / Sync again 6. the new bookmarks are lost, the previous deleted bookmarks reappear. You can disconnect your account via the pref pane with the same result. But that is at least a conscious decision of the user. But sometimes you are no longer logged in without knowing that because you don't use the menu. That's really a problem.
Priority: -- → P1
I am unable to confirm this report: Soren, please attach sync log from just after step 5. Find instructions how to find the logs here: http://philikon.wordpress.com/2011/06/16/aboutsync-log/
Here is my latest sync log. I disconnected my account via preference pane, moved a open tab to the bookmarks toolbar, reconnected my account and the bookmark was gone.
> 3. sometimes it happens that you need to log in again, I don't know why or when that happens. We've tried to address the cases when this was unexpectedly happening. There are some expected cases we will put users in the "re-auth" state, e.g., when you change your password on another machine. We should make sure we continue to track user changes while her machine is in the re-auth state.
You should only enter a 're-authentication' state when you change/reset password. Upon that change, all your connected devices will token will expire and you will have to re-authenticate. There may be more elegant solutions that we could pursue in the near future. Changes made during a unsynced state could not get synced. I doubt that's a regression from sync 1.1 but the new design exposes this a bit more. We should log a bug reguarding delete/add colliding with unsynced clients.
Priority: P1 → P2
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: