I've noticed that the process startup times reported by FHR via nsIAppStartup *seem* to include time spent running the installer/upgrader. This will add seconds to reported times and possibly result in incorrect identification of slow startup. I think we should identify whether startup was delayed by a process not under the user's control (like installer) and report or adjust for this in the reported times. rstrong: could you please provide info on how the installer/upgrader works in terms of process lifetime, specifically how it would impact measurement of startup/shutdown times.
Startup checks if there is an update pending and if it is it applies the update. http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#3464 The firefox process exits while the update is applied. This should happen once approximately every 6 weeks on the release channel if there are no security updates. We have lessened the impact by applying the update to a staged copy and swapping this with the original. With the previous in mind I don't think there is much more we can reasonably do to lessen the impact of there being one startup to to apply an update approximately every 6 weeks. I suspect you could flag startups that need to apply an update in your measurements. Perhaps even report it separately so we can see if startup times which need to apply an update change significantly.
Flagging startups that incurred an update would possibly help with data analysis. Currently, we have no way of knowing if they were an expected or unexpected outlier. Is there any way to determine whether the current session incurred an update?
The flow is essentially http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#3508 http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsUpdateDriver.cpp#912 http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsUpdateDriver.cpp#978 http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsUpdateDriver.cpp#647 http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsUpdateDriver.cpp#857 which is followed by exit(0) when restart evaluates to true
So, I guess the question is whether FHR's session recorder (initialized during profile-after-change notification) is initialized when an update is running. I don't pretend to know my way around nsAppRunner.cpp to know for sure. I guess it's time to go code diving!
Component: Metrics and Firefox Health Report → Client: Desktop
Product: Mozilla Services → Firefox Health Report
Changing summary to avoid confusion with the installer.
Summary: Isolate impact of installer on process start times → Isolate impact of application updating on process start times
I'm not sure, but I'd suspect that this should really be a bug against the startup component, rather than being FHR-specific, since there are other consumers of this data.
Priority: -- → P4
Component: Client: Desktop → Metrics: Pipeline
Product: Firefox Health Report → Cloud Services
investigate on unified telemetry
Hey Stephen, is this something your current work overlaps with? And if so, do you want to take this? If not, we'll close, thanks.
No, this doesn't overlap and it would rank pretty low on my list of priorities if I were to take it, sorry.
As far as updates go the following pref which is provided by app update can be checked by the telemetry code prior to it being cleared. https://dxr.mozilla.org/mozilla-central/source/browser/components/nsBrowserGlue.js#1224 This of course won't handle the case of a secondary user that had Firefox updated (whether that is by a pave over install or an app update) by someone else or the case of using multiple profiles with the same install since the pref is specific to the profile used immediately after an update. I know in the past that those users can have startup affected by the regeneration of the xul cache, etc. though I don't know the status of that now.
Closing abandoned bugs in this product per https://bugzilla.mozilla.org/show_bug.cgi?id=1337972
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.