[Dedicated Profiles] The "restart" action is not recorded by telemetry
Categories
(Toolkit :: Startup and Profile System, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox65 | --- | unaffected |
firefox66 | --- | unaffected |
firefox67 | --- | verified |
People
(Reporter: Ovidiu, Assigned: mossop)
References
(Regressed 1 open bug)
Details
Attachments
(1 file)
Affected versions
- Nightly 67.0a1
Affected platforms
- Mac 10.14, Ubuntu 16.04, Windows 10
Steps to reproduce
- Open the browser
- Go to about:profiles
- Select "Restart Normally"
- After restart go to about:telemetry and select "Scalars"
- Check the "startup.profile_selection_reason" value
Expected result
- The value is "restart"
Actual result
- The value is "default"
The same result is recorded if you close the browser and restarted with the same profile.
Additional notes
- If from about:profiles you select "Restart with Add-ons Disabled" the issue is no longer reproducible.
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 1•6 years ago
|
||
So this is a bit weird. Normally when we initiate a restart from within Firefox we set certain flags to ensure that the new instance uses the same profile as previously. It's these flags that I use to set the telemetry accordingly.
The restart buttons in about:profiles however does something different. It doesn't set the flags and so when Firefox restarts it will just go through normal profile selection again, so you can restart and end up using a different profile. That seems odd and not what I would expect from these buttons. I can't see any mention of why this is in bug 1179129. I'd like to propose that we "fix" this bug by just making these buttons do the normal thing and always restart into the same profile. What do you think Romain?
If we decide not to do that then I'd like to know what we should do in telemetry for this case.
Currently restarts of this kind will just generate one of the "firstrun-" or the "default" result. I could change it so for these restarts we get the "restart-" or the "restart" result but I'm not sure that that is correct since this seems like a different case. I can do pretty much whatever here easily, just need to know what is most useful to you Romain.
Comment 2•6 years ago
|
||
(In reply to Dave Townsend [:mossop] (he/him) from comment #1)
So this is a bit weird. Normally when we initiate a restart from within Firefox we set certain flags to ensure that the new instance uses the same profile as previously. It's these flags that I use to set the telemetry accordingly.
The restart buttons in about:profiles however does something different. It doesn't set the flags and so when Firefox restarts it will just go through normal profile selection again, so you can restart and end up using a different profile. That seems odd and not what I would expect from these buttons. I can't see any mention of why this is in bug 1179129. I'd like to propose that we "fix" this bug by just making these buttons do the normal thing and always restart into the same profile. What do you think Romain?
I agree that users would expect here to restart Firefox with the profile they ran when initiating the restart regardless of whether this was default or not.
I could also not find any mention to that on SUMO.
If we decide not to do that then I'd like to know what we should do in telemetry for this case.
Currently restarts of this kind will just generate one of the "firstrun-" or the "default" result. I could change it so for these restarts we get the "restart-" or the "restart" result but I'm not sure that that is correct since this seems like a different case. I can do pretty much whatever here easily, just need to know what is most useful to you Romain.
Let's use "restart" if time allows.
Assignee | ||
Comment 3•6 years ago
|
||
Comment 5•6 years ago
|
||
bugherder |
Comment 6•6 years ago
|
||
This bug seems to be fixed at the moment but, due to bug 1531719, we will leave the status and flags unchecked and wait for bug 1531719 to be investigated so we can re-verify this fix.
Reporter | ||
Comment 7•6 years ago
|
||
I verified this on Mac OS X 10.14, Windows 10, Ubuntu 16.04 with FF Nightly 67.0a1(2019-03-10) and I can confirm the fix.
Description
•