1957924 - Sync new profile group ID across profiles

Status: VERIFIED FIXED

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

Description

[Dave Townsend [:mossop]]

When a user creates multiple profiles we copy the profile group ID between them so they all share the same ID. When a user opts out of data collection we then reset the profile group ID to a canary value. When opting back in we generate a new profile group ID however we do not sync this between the profiles so all of a user's profiles will end up with different profile group IDs in this case.

So the steps are:

1. Create multiple profiles.
2. Opt out of data collection.
3. Opt back into data collection.

After this all profiles will have different profile group IDs.

Comment 1

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

Scope and understand risk before committing to this for 138 uplift.

Questions from KimB:

• What are the risks of not fixing this for 138?
• Could we fix this in 139 if we don't fix it in 138?

Comment 2

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

We're calling this a blocker and starting work on it now. We will aim to uplift it into 138 Beta.

Conversation thread from Slack:

---

jhirsch
I think the bug here is relatively severe - if a user disables, then re-enables data collection, all of the profiles in a profile group will submit telemetry with different profile group IDs. The UI doesn't break, but the telemetry will lose the linkage between profiles in the group.

It's hard to estimate how often this happens because when a user disables data collection, we permanently delete the client_id tied to that profile. If they later re-enable data collection, we generate a new (random) client_id, and by design, we don't have any way to know that it's the same user with a different client_id--it just looks like a new profile as far as our telemetry system is concerned.

The fix seems relatively small and easy to uplift. I think it makes sense to include it in 138. What do you think?

KimB
Let's try our best to get this in 138.

The thing that convinced me:

It's hard to estimate how often this happens

Comment 3

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

[Tracking Requested - why for this release]:

See comment 2 - this bug breaks profile group glean/telemetry reporting for users who disable then re-enable data reporting. We would like to uplift this fix once it's verified in Nightly.

Comment 4

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

Attachment: Bug 1957924 - Ensure profile group ID is applied to all profiles after re-enabling data collection. r?#profiles-reviewers,chutten

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3ffd7e1d0343
Ensure profile group ID is applied to all profiles after re-enabling data collection. r=profiles-reviewers,mossop

Comment 6

[Serban Stanca [:SerbanS]]

Backed out for causing mochitests failures in browser_preferences.js.

• Backout link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-FAIL | browser/components/profiles/tests/browser/browser_preferences.js | after disabling data collection, the profile group ID pref should have the canary value - "4b884525-d772-4b23-896a-acd4e0fe7c94" == "decafdec-afde-cafd-ecaf-decafdecafde" -

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ad669d3e4f2c
Ensure profile group ID is applied to all profiles after re-enabling data collection. r=profiles-reviewers,mossop

Comment 8

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/ad669d3e4f2c

Comment 9

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

The patch landed in nightly and beta is affected.
:jhirsch, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox138 to wontfix.

For more information, please visit BugBot documentation.

Comment 10

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

Comment on attachment 9476764 [details]
Bug 1957924 - Ensure profile group ID is applied to all profiles after re-enabling data collection. r?#profiles-reviewers,chutten

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: This patch ensures users that disable, then reenable data collection will correctly report the same profile group ID in telemetry pings from profiles in the same profile group.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: * create multiple profiles
• visit about:preferences#privacy
• uncheck the "Send technical and interaction data to Mozilla" checkbox
• then, check the checkbox
• in each profile, open about:config and verify the value of the toolkit.telemetry.cachedProfileGroupID pref is the same for each profile in the profile group.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This patch only affects multiple profiles users, which will be limited to 0.5% of the 138 release population. The code change is low risk: this is a small patch with automated tests that adds one more pref to an already working/tested code path that propagates pref changes between profiles in a group.
• String changes made/needed: None
• Is Android affected?: No

Comment 11

[Dianna Smith [:diannaS]]

Comment on attachment 9476764 [details]
Bug 1957924 - Ensure profile group ID is applied to all profiles after re-enabling data collection. r?#profiles-reviewers,chutten

Approved for 138.0b5

Comment 12

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/bc2d328ff32d

Comment 13

[Dianna Smith [:diannaS]]

Comment on attachment 9476764 [details]
Bug 1957924 - Ensure profile group ID is applied to all profiles after re-enabling data collection. r?#profiles-reviewers,chutten

Backed out of Beta for causing failures on linux webrender jobs

browser/components/profiles/tests/browser/browser_preferences.js | after disabling data collection, the profile group ID pref should have the canary value

Failure log
Failure push
Backout push

Comment 14

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

Attachment: Bug 1957924 - Replace timeout with explicit wait to improve reliability of browser_preferences.js test. r?#profiles-reviewers,chutten

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4621eb83ca05
Replace timeout with explicit wait to improve reliability of browser_preferences.js test. r=chutten,profiles-reviewers,niklas

Comment 16

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

Comment on attachment 9478115 [details]
Bug 1957924 - Replace timeout with explicit wait to improve reliability of browser_preferences.js test. r?#profiles-reviewers,chutten

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: See the other patch on this bug. This patch fixes a test failure and should be uplifted together with the other one (applied after it).
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: other patch on bug 1957924
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): See other patch--it's a low risk patch, and in this additional patch we've simply made the previously failing test more reliable.
• String changes made/needed: None
• Is Android affected?: No

Comment 17

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

It's at my end of day, so requesting uplift before this patch makes its way from autoland to m-c

Comment 18

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/4621eb83ca05

Comment 19

[Dianna Smith [:diannaS]]

Comment on attachment 9476764 [details]
Bug 1957924 - Ensure profile group ID is applied to all profiles after re-enabling data collection. r?#profiles-reviewers,chutten

Approved for 138.0b6

Comment 20

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/33da6b11df03
https://hg.mozilla.org/releases/mozilla-beta/rev/f415ecc98e9d

Comment 21

[Raluca Popovici, Desktop QA]

Verified the fix on macOS 13.2.1, Windows 11 using Nightly 139(10-04-2025) and Beta treeherder build 138.0b6.
When "Send technical and interaction data to Mozilla" is unchecked, the value for "toolkit.telemetry.cachedProfileGroupID" will be 'decafdec-afde-cafd-ecaf-decafdecafde' for all profiles, all the time.
What should happen in the following scenario:
Device 1: Profile 1 with FxA1 and "Send technical and interaction data to Mozilla" is unchecked.
Device 2: Profile 2 with the same FxA1 but "Send technical and interaction data to Mozilla" is checked, including "Allow personalized extension recommendations" and "Install and run studies" checkboxes.
Actual result: After sync, Profile 1 is not updated, and the "Send technical and interaction data to Mozilla" checkbox remains unchecked.

Questions:

1. Should Profile 1 be updated after sync? Shouldn't the "Allow personalized extension recommendations" and "Install and run studies" checkboxes also be checked?
   If yes, the value for "toolkit.telemetry.cachedProfileGroupID" should also change.

Comment 22

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

Hi Raluca - Great catch! Yes, the behavior you're describing is expected, given the current unmanaged interaction between local per-device pref copying done by profiles and cross-device pref copying done by firefox sync.

If a user has multiple profiles on multiple devices, and uses firefox sync to manage preferences between pairs of profiles on each device, the result is a nondeterministic race, where the device that syncs to the server first will "win the race" and set the value for the other device. This is a known issue that is not currently considered a blocker.

Comment 23

[Raluca Popovici, Desktop QA]

According to the comment 22 I will close this bug as verified.