1996995 - [meta] Ensure Sync and Profiles don't try to manage the same preferences

Status: NEW

(Toolkit :: Startup and Profile System, defect, P2)

Description

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

Summary

Both Firefox Sync and the new Profiles feature have the ability to synchronize the state of prefs between different profiles, and we should ensure these two systems don't attempt to manage the same preferences, which could lead to unexpected behavior.

In the case of Sync, prefs are typically synced between profiles on separate devices.

In the case of Profiles, prefs are typically copied between profiles located in a single user OS account on a single device.

Why this is a problem

Having two disconnected systems responding to pref state flips opens us up to exotic and strange bugs like:

• a user has a profile group on a desktop device, with two profiles in a profile group, and one profile syncing with their "work" account, and another profile signed into sync with their "personal" account.
• the user unchecks the box on their mobile device which syncs with the "personal" account.
• sync unsets the browser.discovery.enabled pref on the desktop profile tied to the "personal" account.
• profiles propagates the pref flip to the other profile in the profile group, tied to the "work" account.
• the user's work device flips the pref unexpectedly.

This situation gets more complicated if a profile group is shared by multiple different people, and each profile is signed into a different sync account tied to a different phone or additional desktop device.

The specific bug at hand

In bug 1933264 (shipped in Firefox 138), we decided to have all of the data collection prefs copied between profiles in a group, on the thinking that this approach reflected both the principle of least surprise (since we think of a profile group as belonging to one person, making a profile group's data settings consistent likely reflects that person's intent) and the principle of maximum privacy (if someone disables certain data-related prefs in one profile, they probably meant that for the whole profile group). And it's also a nicer user experience to not annoy users with the terms of use popup in additional profiles after they have accepted the ToU once.

However, it turns out that Sync is already managing one of these prefs, browser.discovery.enabled.

Steps we should take

Based on discussion with :markh, initially we can just remove the line from firefox.js that enables syncing that pref (the services.sync.prefs.sync.browser.discovery.enabled pref line).

To avoid this happening in the future, we should consider the following:
(1) add a check to SelectableProfileService and refuse to add a pref "foo" to the SharedPrefs list if there is a corresponding "services.sync.prefs.sync.foo" pref already set in the profile,
(2) add a Profiles test that verifies none of the permanentSharedPrefs are synced
(3) either make the permanentSharedPrefs list public on the SelectableProfileService, so that Sync can refuse to sync a pref that's in that list, or have Sync call SelectableProfileService.getAllDBPrefs() to ensure we don't sync a dynamically added pref.