1614349 - Resetting FxA Password resets sync engines to having them all enabled.

Status: RESOLVED DUPLICATE of bug 1572344

(Firefox :: Sync, defect)

Description

[Ana Medinac]

I tested this on Firefox Nightly and only with one device.

Steps to reproduce:

1. Create an account where I only enabled 2 engines (Open Tabs, and Bookmarks)
2. Sign out of the FxA account
3. Sign back in through the Forgot Password flow
4. Go to Sync settings and notice that all my engines have been enabled.

I expected to only have the 2 engines enabled (Open Tabs, and Bookmarks), we also don't warn the user that all the engines have been re-enabled, instead they have to figure out by themselves that they have all been turned on.

Comment 1

[Ryan Kelly [:rfkelly]]

I agree this is suboptimal behaviour, so not trying to argue it's working how it should be, just adding some notes on why I think it's behaving how it is...

Sign out of the FxA account

This causes the browser to forget about the sync state for that account, including forgetting the user's sync data choices (because they're a property of the account, not the browser instance).

Sign back in through the Forgot Password flow

Your sync data choices are stored on the sync storage node, and resetting your FxA password means you get allocated to a new storage node. So when you sign back in to the browser, it looks in sync for your data choices, doesn't find any, and defaults to enabling all the things.

One way to fix this is to store the user's data choices somewhere more permanent, rather than storing them on the sync storage node. We don't encrypt them anyway, so there's no value in throwing them away when the password gets reset.

Another way to fix this would be Bug 1572344 - if the user doesn't have any data choices recorded, we should ask them to choose what to sync rather than defaulting them in to syncing everything.

Comment 2

[Mark Hammond [:markh] [:mhammond]]

To follow up from my comment in the meeting today. I didn't understand this, but now I've re-read it, I agree with Ryan (ie, I now do understand)

The problem here is that we explicitly disconnected from Sync and FxA on the only device which knew what the data choices were. This disconnection process explicitly deletes all local info about Sync - including what the data choices were. If we performed the reset without explicitly disconnecting I would have expected us to recover.

We could not delete this info locally, but I don't think that would help the actual use-cases here - I think the more likely scenario is that the user replaced an existing device - in which case we still would be in the same boat - so I don't think there's any action we can take here beyond what Ryan said (ie, consider this as part of the general CWTS project)

Sorry for the noise.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:markh, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 4

[Mark Hammond [:markh] [:mhammond]]

(In reply to Mark Hammond [:markh] [:mhammond] from comment #2)

so I don't think there's any action we can take here beyond what Ryan said (ie, consider this as part of the general CWTS project)

So yeah, it's a dupe of the CWTS effort.