1965598 - The Usage Profile Group ID should be shared by all profiles in a group

Status: ASSIGNED

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

Description

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

While we added a new usage profile group identifier in bug 1944648, that implementation creates one per profile, not one per profile group.

We need to ensure that all profiles in a group share the same usage profile group ID--doesn't matter which one becomes the leader, just matters that they all share that identifier.

Comment 1

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

Set release status flags based on info from the regressing bug 1944648

Comment 2

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

I think there are now two separate problems here:

1. If multiple profiles in a group have different usage profile group IDs, we need to pick one.

2. A newly created profile in a group should inherit the usage profile group ID from the profile that created it.

(2) seems easier to solve, since we save the usage profile group ID in a pref, and we already set certain prefs into new profiles at creation time. We'll just need to make sure we read in that pref value at first run and set it using ClientID.setUsageProfileGroupID.

Choosing a leader in (1) seems harder: we can set the usage profile group ID as a shared pref, and so copy it around to all profiles in a group, but we can't enforce an ordering for when each profile in the group will get that pref value and compare it against its own. Maybe we can rely on the fact that we do have a total ordering, since all UUIDs can be sorted using alphanumeric sorting? So the solution might be something like, "if my usage profile group ID comes before the one in shared prefs, overwrite the shared pref with mine, otherwise overwrite mine".

Comment 3

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

The bug is marked as tracked for firefox139 (beta) and tracked for firefox140 (nightly). We have limited time to fix this, the soft freeze is in 10 days. However, the bug still isn't assigned.

:pluk, could you please find an assignee for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 4

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

I wrote the regressor, so I'll take this bug, too.

I need to discuss with the team to see if we want to try to get a very late fix into 139. We may just live with it for 139 and land a fix in 140.

Comment 5

[Ryan VanderMeulen [:RyanVM]]

Hi Jared, any updates on those discussions?

Comment 6

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

Hi - yes, working on a fix, targeting 140.

Comment 7

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

Set release status flags based on info from the regressing bug 1944648

Comment 8

[Donal Meehan [:dmeehan]]

Fx140 is now in Beta, with just over 2 weeks before it goes to RC.
:jhirsh, are you still targeting Fx140 or do you think this might slip to Fx141?

Comment 9

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

Hi Donal, thanks for checking in. It's likely this will slip to 141.

Comment 10

[Donal Meehan [:dmeehan]]

Setting Fx140 to fix optional, in case there's a low risk fix in time

Comment 11

[Pascal Chevrel:pascalc (PTO until Sept 2)]

(In reply to Jared Hirsch [:jhirsch] (he/him) (Needinfo please) from comment #9)

Hi Donal, thanks for checking in. It's likely this will slip to 141.

Hi Jared, is this still targeting 141? Thanks

Comment 12

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

We can move it to 142.