michaeln@chromium.org The number of after-startup tasks that were queued prior to startup completion and deferred until that time. michaeln@chromium.org Time from the process creation until deferred after-startup tasks began running. The histogram was expired and extended in M119 again. mthiesse@chromium.org pasko@chromium.org Records the first type of component created after process creation - most likely the reason the process was created - at the time the component is created on Android P+. Differences in distribution between Android versions (particularly with respect to ContentProviders) likely indicate a change to Android startup that broke our detection. nafisabedin@google.com pasko@chromium.org The time from process creation to FirstContentfulPaint happening in this activity. Cold start is determined by whether the process creation reason is Activity. This also filters out non-Activity launches. Recorded only for tabbed activity and on cold starts. Therefore it cannot be recorded more than once in the application lifetime. Preserves the same recording semantics as Startup.Android.Cold.TimeToFirstContentfulPaint3.{StartActivityType}. nafisabedin@google.com pasko@chromium.org The time from process start to the FirstNavigationCommit happening for a particular {StartActivityType}. Cold start is determined by whether the process creation reason is Activity. This also filters out non-Activity launches. Recorded for both Tabbed Activities and WebApks only during cold starts. Preserves the same recording semantics as Startup.Android.Cold.TimeToFirstNavigationCommit3.{StartActivityType}. nafisabedin@google.com pasko@chromium.org The time from process start to the moment Chrome first appears ready to the user. Cold start is determined by whether the process creation reason is Activity. This also filters out non-Activity launches. Recorded once per application launch and only during cold starts. Preserves the same recording semantics as Startup.Android.Cold.TimeToFirstVisibleContent4. xinghuilu@chromium.org nafisabedin@google.com chrome-counter-abuse-alerts@google.com The time it took GmsCore SafeBrowsing API to respond to the first SafeBrowsing request for the Tabbed Activity during a cold start. Cold start is determined by whether the process creation reason is Activity. Similarly to Startup.Android.Cold.TimeToFirstVisibleContent2 omits recording a sample: 1. when the first Activity is a CCT/WebAPK/TWA, 2. when an error page is committed, 3. for non-http(s) pages, 4. for downloads, 5. when another activity was shown and hidden before the first navigation committed, 6. when the first navigation was preceded by showing a NTP (New Tab Page). This v2 metric is recorded at the same time as Startup.Android.Cold.TimeToFirstNavigationCommit3.Tabbed, utilizing ColdStartTracker. Only logged if the URL of the first navigation is checked by SafeBrowsing API. NOTE: This metric is broken before October 2024 on Pixel 6+ on Android 14+ due to an issue with the recording of BrowserProcessCreationReason affecting ColdStartTracker downstream. pasko@chromium.org nafisabedin@google.com The time from activity creation on a cold start to FirstContentfulPaint happening in this activity. Cold start is determined by whether the process creation reason is Activity. Recorded only for tabbed activity and on cold starts. Therefore it cannot be recorded more than once in the application lifetime. Similarly to Startup.Android.Cold.TimeToFirstVisibleContent2 omits recording a sample: 1. when the first Activity is a CCT/WebAPK/TWA, 2. when an error page is committed, 3. for non-http(s) pages, 4. for downloads, 5. when another activity was shown and hidden before the first navigation committed, 6. when the first navigation was preceded by showing a NTP (New Tab Page). This v3 metric uses ColdStartTracker and is a rename for Startup.Android.Experimental.FirstContentfulPaint.Tabbed. It otherwise preserves the same semantics and aims to replace the original v1 metric as well. NOTE: This metric is broken before October 2024 on Pixel 6+ on Android 14+ due to an issue with the recording of BrowserProcessCreationReason affecting ColdStartTracker downstream. {StartActivityType} nafisabedin@google.com yfriedman@chromium.org The time from process start to the moment the first frame is drawn for the app, as determined by Android. Recorded regardless of what is loaded (i.e. NTP, web, etc.). The intent is to provide a general overview of user-perceived cold start time. Recorded once per application launch, only when the start is determined to be cold. Utilizes ApplicationStartInfo's getStartComponent() which is only available starting with Android 16. The metric isn't recorded if Chrome is backgrounded in between activity creation and recording of the metric. pasko@chromium.org agrieve@chromium.org nafisabedin@google.com The time from activity creation on a cold start to the FirstNavigationCommit happening for a particular {StartActivityType}. Cold start is determined by whether the process creation reason is Activity. Recorded for both Tabbed Activities and WebApks only during cold starts. Omits recording a sample: 1. when the first Activity is a CCT/TWA, 2. when an error page is committed, 3. for non-http(s) pages, 4. for downloads, 5. when another activity was shown and hidden before the first navigation committed, 6. when the first navigation was preceded by showing a NTP (New Tab Page). NOTE: This metric is broken before October 2024 on Pixel 6+ on Android 14+ due to an issue with the recording of BrowserProcessCreationReason affecting ColdStartTracker downstream. yfriedman@chromium.org pasko@chromium.org fredmello@chromium.org nafisabedin@google.com chrome-ds@google.com The time from the first Chrome tabbed activity creation to the moment Chrome first appears ready to the user. This metric captures when the omnibox is painted and either a navigation has committed or a Paint Preview is shown. The intent is to reflect Clank's perceived cold start performance regardless of different launch paths, while controlling for the factors that we have the most direct influence over and minimizing external factors. Note that network connectivity is mostly but not entirely omitted as it does impact the initial response time for a site which impacts the omnibox UX and loading metric. This metric captures the value of the first emitted metric out of the 'Startup.Android.Cold.TimeToFirstNavigationCommit3.Tabbed' and 'Browser.PaintPreview.TabbedPlayer.TimeToFirstBitmap' metrics and emits the value, skipping the record when both are missing. This metric is only recorded once per application lifetime, and only for the cold starts. An important requirement for the startup to be Cold is that the Tabbed Activity has to be the process creation Reason. See histogram Startup.Android.BrowserProcessCreationReason and code in ColdStartTracker. Determining the process creation reason is only reliable starting at Android P. Specifically, it is recorded for the first foreground committed http(s) URL in the primary frame if that first navigation is not: an error, same-document navigation, or fragment navigation. This metric is not recorded: - If another navigation occurs before the first navigation commit and the Paint Preview show. - If the navigation is pre-warmed, is a background navigation, or fails to be committed (e.g. cancelled, network error, or error due to lack of connectivity). - If the activity was ever backgrounded between activity creation and this metric reporting. - If the app opens to the Chrome Start page. - For WebApps, PWAs or WebApks. - For NTP. This metric is expected be stable from milestone to milestone. Updating Chrome or the Android system image on the device are expected to result in a noticeable slowdown on the first cold startup after. This histogram is of special interest to the chrome-ds@. Do not change its semantics or retire it without talking to them first. ckitagawa@chromium.org nafisabedin@google.com Android: The time from the activity creation point to the moment the content may first appear ready to a user. The intent is to capture readiness of Chrome regardless of whether Chrome is launched into native UI or a web page. The recorded value is the minimum of 'Startup.Android.Cold.TimeToFirstContentfulPaint3.Tabbed' 'Browser.PaintPreview.TabbedPlayer.TimeToFirstBitmap' metric values. This metric is only recorded once per application lifetime, and only for cold starts. TimeToFirstContentfulPaint3.Tabbed utilizes ColdStartTracker which is only reliable starting with Android P as ProcessCreationReason is used to determine cold starts. pasko@chromium.org nafisabedin@google.com clhager@google.com The time from activity creation on a cold start to FirstContentfulPaint happening in this activity. Cold start is determined by whether the process creation reason is Activity. Recorded only for tabbed activity when persistent state is being restored and on cold starts. Therefore it cannot be recorded more than once in the application lifetime. Similarly to Startup.Android.Cold.TimeToFirstVisibleContent2 omits recording a sample: 1. when the first Activity is a CCT/WebAPK/TWA, 2. when an error page is committed, 3. for non-http(s) pages, 4. for downloads, 5. when another activity was shown and hidden before the first navigation committed, 6. when the first navigation was preceded by showing a NTP (New Tab Page). This v3 metric uses ColdStartTracker and is a rename for Startup.Android.Experimental.FirstContentfulPaint.Tabbed. It otherwise preserves the same semantics and aims to replace the original v1 metric as well. NOTE: This metric is broken before October 2024 on Pixel 6+ on Android 14+ due to an issue with the recording of BrowserProcessCreationReason affecting ColdStartTracker downstream. {StartActivityType} yfriedman@chromium.org pasko@chromium.org fredmello@chromium.org nafisabedin@google.com clhager@google.com chrome-ds@google.com The time from the first Chrome tabbed activity creation to the moment Chrome first appears ready to the user, if the activity was launched by the system with persistent state to be restored. This metric captures when the omnibox is painted and either a navigation has committed or a Paint Preview is shown. The intent is to reflect Clank's perceived cold start performance regardless of different launch paths, while controlling for the factors that we have the most direct influence over and minimizing external factors. Note that network connectivity is mostly but not entirely omitted as it does impact the initial response time for a site which impacts the omnibox UX and loading metric. This metric captures the value of the first emitted metric out of the 'Startup.Android.Cold.TimeToFirstNavigationCommit3.Tabbed' and 'Browser.PaintPreview.TabbedPlayer.TimeToFirstBitmap' metrics and emits the value, skipping the record when both are missing. This metric is only recorded once per application lifetime, and only for the cold starts. An important requirement for the startup to be Cold is that the Tabbed Activity has to be the process creation Reason. See histogram Startup.Android.BrowserProcessCreationReason and code in ColdStartTracker. Determining the process creation reason is only reliable starting at Android P. Specifically, it is recorded for the first foreground committed http(s) URL in the primary frame if that first navigation is not: an error, same-document navigation, or fragment navigation. This metric is not recorded: - If another navigation occurs before the first navigation commit and the Paint Preview show. - If the navigation is pre-warmed, is a background navigation, or fails to be committed (e.g. cancelled, network error, or error due to lack of connectivity). - If the activity was ever backgrounded between activity creation and this metric reporting. - If the app opens to the Chrome Start page. - For WebApps, PWAs or WebApks. - For NTP. This metric is expected be stable from milestone to milestone. Updating Chrome or the Android system image on the device are expected to result in a noticeable slowdown on the first cold startup after. This histogram is of special interest to the chrome-ds@. Do not change its semantics or retire it without talking to them first. nafisabedin@google.com yfriedman@chromium.org The time from the start of the activity on a cold start until the first draw pass on the root view (for Java NTP) or first visually non-empty paint (for WebUI NTP). This usually indicates when the fixed UI elements are shown to the user, but the articles might not be filled in yet. Metric is recorded once per application lifetime during a cold start. Utilizes ColdStartTracker to determine if a start was cold based on process creation reason. Therefore, it is recommended to limit analysis of the data to Android P+ because on prior versions the cold start detection is time-based and therefore less robust. nafisabedin@google.com yfriedman@chromium.org Records the total time spent handling Binder calls on a cold start for a particular {StartupType}. Metric is recorded once per application lifetime during a cold start, only when the cold start metric (e.g. TimeToFirstDraw) pertaining to {StartupType} is also recorded. The underlying mechanism used to determine this relies on undocumented Android APIs, meaning that it may break in the future. nafisabedin@google.com yfriedman@chromium.org Records the total number of Binder transactions made during a cold start for a particular {StartupType}. Metric is recorded once per application lifetime during a cold start, only when the cold start metric (e.g. TimeToFirstDraw) pertaining to {StartupType} is also recorded. The underlying mechanism used to determine this relies on undocumented Android APIs, meaning that it may break in the future. hanxi@chromium.org xinyiji@chromium.org Android: The elapsed time from the last time when Chrome goes to background till it becomes foreground again. The histogram is recorded when onResumeWithNative() is called. hanxi@chromium.org wychen@chromium.org Records the time duration from a cold start until the first draw pass of the native Android View hierarchy completes (specifically, the android.R.id.content view). This reflects the time until the native Chrome app shell or placeholder UI is painted to the screen by Android, which occurs well before the web renderer paints the actual page content (which is tracked by metrics like Startup.FirstWebContents.NonEmptyPaint3). mthiesse@chromium.org yfriedman@chromium.org Measures the amount of time startup has likely been delayed due to GURL waiting on the native library to be initialized. martinkong@google.com agrieve@chromium.org The time spent in InitializeFeatureList.initializeFeatureList() during process startup. This measures how long the C++ FeatureList creation takes during early startup. hanxi@chromium.org xinyiji@chromium.org Android: Records whether the last time when Chrome went to background or closed was logged. The histogram is recorded when onResumeWithNative() is called. hanxi@chromium.org xinyiji@chromium.org Android: Records whether the last time when Chrome was showing in foreground was logged. The histogram is recorded when onResumeWithNative() is called. nafisabedin@google.com yfriedman@chromium.org The total time a user waits for the Clank startup ablation study. The enabled arms of the study prescribes an amount of time to delay the launch of Clank, and this histogram records the amount of time waited to verify ablation and any additional delay. Recorded only when the main Chrome launcher icon is used to start the app (i.e. LaunchCauseType is MAIN_LAUNCHER_ICON or MAIN_LAUNCHER_ICON_SHORTCUT) and after the ablation occurs. nafisabedin@google.com yfriedman@chromium.org Records whether Chrome started cold or warm when the main Chrome launcher icon is used to start the app i.e. LaunchCauseType is MAIN_LAUNCHER_ICON or MAIN_LAUNCHER_ICON_SHORTCUT. Utilizes ColdStartTracker to determine if a start was cold based on process creation reason. Therefore, it is recommended to limit analysis of the data to Android P+ because on prior versions the cold start detection is time-based and therefore less robust. NOTE: This metric is broken before October 2024 on Pixel 6+ on Android 14+ due to an issue with the recording of BrowserProcessCreationReason affecting ColdStartTracker downstream. mschillaci@google.com agazal@google.com twellington@google.com Records the type of optional promo shown during startup, if any. Optional promos are from the TabbedRootUICoordinator's "maybeShowPromo" method, which have the lowest priority in the queue. Recorded when a promo is chosen to show. The "None shown" (NONE_SHOWN) bucket refers only to this method's return and not promos in general, i.e. some feature implementations may trigger a promo from a different location (e.g. notification opt-in). nafisabedin@google.com mthiesse@chromium.org Records the component type that was being started which triggered the start as determined by Android's ApplicationStartInfo API. Only available starting with Android B and above. nafisabedin@google.com yfriedman@chromium.org Uses Android's ApplicationStartInfo API to determine the temperature of the start: unset, cold, warm or hot every time Clank is brought to the foreground. Only available starting with API Level 35. nafisabedin@google.com mthiesse@chromium.org Records the time duration from a warm, main intent launch until the first draw completes. peter@chromium.org Records the cause, each time Chrome is brought to the foreground. Currently only checks if a NotificationUIManager notification was shown in the last 5 seconds (includes Web Notifications, but not media or Cast). robliao@chromium.org The amount of time that elapsed during BrowserMainRunnerImpl::Initialize. gab@chromium.org etienneb@chromium.org Time from application start to the first time MainMessageLoopRun() reaches idle. This is a new (Feb'2021) metric intended to capture UI jank caused by the long queue of tasks post initialization. This is believed to capture performance issues (startup responsiveness) none of the other Startup.* metrics capture (crbug.com/1175074). Recording is dropped if blocking UI is shown before first-idle is reached (as this blocks main loop progress on unbounded user interaction). On ChromeOS: Was not being recorded when the device started at the login screen. Fixed in M129. {StartupTemperature} etienneb@chromium.org gab@chromium.org Time between Startup.BrowserMessageLoopStartTime and Startup.FirstWebContents.NonEmptyPaint2. Recorded explicitly to allow easy breakdown of Startup.FirstWebContents.NonEmptyPaint2 when diagnosing issues. On ChromeOS: This metric was broken before M129. The code considered displaying the login screen as impeding the initial foreground tab even though a browser window doesn't even exist at that stage. Since it's common for the device to boot to the login screen, this metric was being recorded a small percentage of the time. This metric was fixed in M129 to be recorded for the active browser window's initial foreground tab from a full ChromeOS user session restore. However, since the arbitrarily long amount of time that the user spends at the login screen is incorporated into this measurement, it is highly recommended to analyze Startup.FirstWebContents.NonEmptyPaint3 instead. {StartupTemperature} fdoray@chromium.org gab@chromium.org Time from application start to the start of the main thread's message loop. Recorded for a first run of the browser. April 8, 2020: Changed the reference from process creation to application start. See Startup.FirstWebContents.NonEmptyPaint3 for a definition of application start. On ChromeOS: Was not being recorded when the device started at the login screen. Fixed in M129. fdoray@chromium.org gab@chromium.org Time from application start to the start of the main thread's message loop. Not recorded for first run. April 8, 2020: Changed the reference from process creation to application start. See Startup.FirstWebContents.NonEmptyPaint3 for a definition of application start. On ChromeOS: Was not being recorded when the device started at the login screen. Fixed in M129. {StartupTemperature} joenotcharles@google.com gab@chromium.org Recorded when SetBrowserStartupIsComplete() is called, indicating the reason browser startup has been marked complete. gab@chromium.org mblsha@yandex-team.ru Time from application start to the time the first Browser window has finished painting its children. April 8, 2020: Changed the reference from process creation to application start. See Startup.FirstWebContents.NonEmptyPaint3 for a definition of application start. On ChromeOS: This metric was broken before M129. The code considered displaying the login screen as impeding the initial foreground tab even though a browser window doesn't even exist at that stage. Since it's common for the device to boot to the login screen, this metric was being recorded a small percentage of the time. This metric was fixed in M129 to be recorded for the active browser window's initial foreground tab from a full ChromeOS user session restore. The latency is measured from the time the browser window restore begins, rather than application start. Browser window restore begins after login either immediately or after the user clicks a notification prompting them to do so, depending on their settings. If the user did not have a Chrome browser window open in the previous session, this metric is not recorded. {StartupTemperature} fdoray@chromium.org gab@chromium.org Time from application start to the time the browser window initially becomes visible. April 8, 2020: Changed the reference from process creation to application start. See Startup.FirstWebContents.NonEmptyPaint3 for a definition of application start. {StartupTemperature} aattar@google.com olivierli@chromium.org Approximate number of bytes loaded via hard faults in the browser process {HardFaultCheckpoint}. This is a normalized metric calculated as (HardFaultCount * OSPageSize) to allow comparison between platforms with different page sizes (e.g. 16KB on Apple Silicon Mac vs 4KB on Windows/Linux/Intel Mac). Note that this is a lower bound since a single page-in operation can read multiple pages. aattar@google.com olivierli@chromium.org chrisha@chromium.org fdoray@chromium.org The cumulative number of hard faults (page-in operations) recorded in the browser process {HardFaultCheckpoint}. On Windows this is derived from SYSTEM_PROCESS_INFORMATION.HardFaultCount; on macOS from Mach task_info (pageins); on Linux from getrusage (ru_majflt). Absolute values are not directly comparable across platforms, and may not be comparable even between OS versions (as changes to how the OS starts and times the startup of applications can affect the metrics). This counts OS-level page-in operations rather than individual pages. A single operation may read multiple pages. justincohen@chromium.org olivierrobin@chromium.org The duration of all initializations from the call to main to UI ready to receive input. iOS specific, from M125+ The process can only be created in response to a user action, either tapping the icon, tapping a link that opens in Chrome, or using the app switcher to switch to Chrome after it has been background-killed by the OS. The metric is recorded at the point where the Chrome window starts receiving input events like touches and keypresses. However, the Chrome splash screen is showing at this point, so there aren't any UI elements for a user to interact with. It does not include code loading and static initializers. The total counts in this histogram can be compared with the number of emits to the user action MobileWillEnterForeground. The former reports the number of cold starts. The latter is only recorded when Chrome comes to the foreground on non-cold starts. {StartupTemperature} olivierrobin@chromium.org justincohen@chromium.org [IOS] The number of time [UIApplicationDelegate application:didFinishLaynching] was called but no scene was activated. Recorded when first scene is becomes active. olivierrobin@chromium.org justincohen@chromium.org [IOS] The number of time +load was called but no scene was activated. Recorded when first scene is becomes active. spvm@chromium.org etienneb@chromium.org catan-team@chromium.org Whether the session restore crash bubble was shown on startup. Recorded once every startup, during early startup, when initializing the infobar. Recorded only on platforms with the crash bubble (i.e. desktop). fdoray@chromium.org gab@chromium.org How long it takes to load the original profile synchronously on the UI thread. ganesh@chromium.org grt@chromium.org Records the time it took for the creation attempt of the ProcessLauncher COM class when {Status}. The `AtStartup` variants record the creation attempt times for when Windows has just started up, and the non-`AtStartup` variants record the creation attempt times for all the other cases. Only recorded on Windows. fdoray@chromium.org gab@chromium.org [Desktop] The reason for which startup profiling was deemed complete. Logged once per session on startup. On ChromeOS: This metric was broken before M129. Since the device typically boots to the login screen (at which point a browser window doesn't exist), `kAbandonNoInitiallyVisibleContent` was recorded most of the time. WebContents-related startup metrics were fixed in M129 to be recorded after login during a full ChromeOS user session restore. `kDone` is expected to be the predominant recording after the fix. fdoray@chromium.org gab@chromium.org chrdavis@microsoft.com [Desktop] Measure the elapsed time from the application start to the first contentful paint of the first web contents. Only comprised of cases where the initial foreground tab gets to complete its rendering task unimpeded. Application start is a time recorded as early as possible in the startup process. See Startup.FirstWebContents.NonEmptyPaint3 for a definition of application start. fdoray@chromium.org gab@chromium.org chrdavis@microsoft.com [Desktop] Measure the elapsed time from the application start to the largest contentful paint of the first web contents. Only comprised of cases where the initial foreground tab gets to complete its rendering task unimpeded. Recorded at page completion. Application start is a time recorded as early as possible in the startup process. See Startup.FirstWebContents.NonEmptyPaint3 for a definition of application start. fdoray@chromium.org gab@chromium.org [Desktop] Measure the elapsed time from application start to the moment when the navigation is committed (first bytes received) in the first web contents' main frame. April 8, 2020: Changed the reference from process creation to application start. See Startup.FirstWebContents.NonEmptyPaint3 for a definition of application start. On ChromeOS: This metric was broken before M129. The code considered displaying the login screen as impeding the initial foreground tab even though a browser window doesn't even exist at that stage. Since it's common for the device to boot to the login screen, this metric was being recorded a small percentage of the time. This metric was fixed in M129 to be recorded for the active browser window's initial foreground tab from a full ChromeOS user session restore. The latency is measured from the time the browser window restore begins, rather than application start. Browser window restore begins after login either immediately or after the user clicks a notification prompting them to do so, depending on their settings. If the user did not have a Chrome browser window open in the previous session, this metric is not recorded. {StartupTemperature} fdoray@chromium.org gab@chromium.org [Desktop] Measure the elapsed time from application start to the beginning of navigation in the first web contents' main frame. April 8, 2020: Changed the reference from process creation to application start. See Startup.FirstWebContents.NonEmptyPaint3 for a definition of application start. On ChromeOS: This metric was broken before M129. The code considered displaying the login screen as impeding the initial foreground tab even though a browser window doesn't even exist at that stage. Since it's common for the device to boot to the login screen, this metric was being recorded a small percentage of the time. This metric was fixed in M129 to be recorded for the active browser window's initial foreground tab from a full ChromeOS user session restore. The latency is measured from the time the browser window restore begins, rather than application start. Browser window restore begins after login either immediately or after the user clicks a notification prompting them to do so, depending on their settings. If the user did not have a Chrome browser window open in the previous session, this metric is not recorded. {StartupTemperature} atharvmaan@google.com chrome-desktop-ui-waterloo@google.com Similar to Startup.FirstWebContents.NonEmptyPaint3, but recorded only for browser launches initiated automatically by the OS. etiennep@chromium.org fdoray@chromium.org gab@chromium.org chrome-ds@google.com [Desktop] Measure the elapsed time from the application start to the first non empty paint of the first web contents. Only comprised of cases where the initial foreground tab gets to complete its rendering task unimpeded (an improvement over Startup.FirstWebContents.NonEmptyPaint). Application start is a time recorded as early as possible in the startup process. On Windows, application start is when chrome.exe:main starts, before chrome.dll is loaded. On other platforms, it is when ChromeMainDelegate is constructed. On ChromeOS: This metric was broken before M129. The code considered displaying the login screen as impeding the initial foreground tab even though a browser window doesn't even exist at that stage. Since it's common for the device to boot to the login screen, this metric was being recorded a small percentage of the time. This metric was fixed in M129 to be recorded for the active browser window's initial foreground tab from a full ChromeOS user session restore. The latency is measured from the time the browser window restore begins, rather than application start. Browser window restore begins after login either immediately or after the user clicks a notification prompting them to do so, depending on their settings. If the user did not have a Chrome browser window open in the previous session, this metric is not recorded. If kWebUIReloadButtonDeferBrowserViewShow is enabled, the browser window display is deferred until the initial WebUI is ready. The measurement initiates using the first active WebContents without requiring its strict visibility, and the measurement is recorded in the same way once that WebContents gets to complete its first non-empty painting. Do not modify this metric in any way without contacting chrome-ds@google.com. {StartupTemperature} spvm@chromium.org etienneb@chromium.org Time from when the application started to when the GPU finishes its initialization. Application start is a time recorded as early as possible in GPU process startup. On Windows, application start is at the start of the GPU process' chrome.exe:main, before chrome.dll is loaded. On other platforms, it is when ChromeMainDelegate is constructed. It should be noted that this does not include rendezvous starts, since in that case, a new GPU process is not launched. This metric is recorded every time the GPU process finishes its initialization, including the case where the process restarts several times during the same browser session. This does not include the GPU info collection process, as that process does not use the GpuServiceImpl. spvm@chromium.org etienneb@chromium.org Time from when ChromeMain was entered in the GPU process to when the GPU finishes its initialization. This metric is recorded every time the GPU process finishes its initialization, including the case where the GPU process restarts several times during the same browser session. spvm@chromium.org etienneb@chromium.org Time from when the GPU process was created according to the OS, to when the GPU finishes its initialization. Mostly useful on Windows, where much time is spent in pre-main. This metric is recorded every time the GPU process finishes its initialization, including the case where the GPU process restarts several times during the same browser session. arabm@google.com dullweber@chromium.org chrome-incognito@google.com Records whether Incognito switch was present in commmand line switches and if Incognito mode was enforced or denied. This is recorded during browser startup when commandline is processed. jlebel@chromium.org chrome-signin-team@chromium.org Records session type for a cold start. It is recorded at cold start. Histogram only for iOS. atharvmaan@chromium.org top-chrome-desktop-ui@google.com Records user interactions with the {StartupLaunchInfoBarType} infobar. atharvmaan@chromium.org top-chrome-desktop-ui@google.com Records how many times {StartupLaunchInfoBarType} infobar has been shown to the user. atharvmaan@chromium.org top-chrome-desktop-ui@google.com Records the new value of the {StartupLaunchMode} launch on login preference when it is changed by the user. fdoray@chromium.org etiennep@chromium.org gab@chromium.org Time from the application start to the C++ ChromeMain() function being invoked. On ChromeOS: Was not being recorded when the device started at the login screen. Fixed in M129. {StartupTemperature} fdoray@chromium.org etiennep@chromium.org gab@chromium.org Time from the process creation to application start, i.e. time recorded as early as possible in the startup process. On ChromeOS: Was not being recorded when the device started at the login screen. Fixed in M129. {StartupTemperature} spvm@chromium.org fdoray@chromium.org Whether Process::Current().CreationTime() was able to acquire the process startup time. Recorded once per process startup, as early as possible. thegreenfrog@chromium.org olivierrobin@chromium.org The action requested on the application startup when called from another app or the OS. thegreenfrog@chromium.org olivierrobin@chromium.org The calling application (if any). spvm@chromium.org etienneb@chromium.org Error code returned by ::SetProcessInformation() when overriding the prefetch parameter for subsequent browser launches. On success, ERROR_SUCCESS is recorded. On failure, the result of ::GetLastError() is used. Recorded when a user is in the kOverridePrefetchOnSingleton experiment, and reaches PostEarlyInitialization(). It is therefore recorded at most once per browser process launch. See crbug.com/380088804 for details. rkaplow@chromium.org The amount of time that elapsed during ChromeBrowserMainParts::PreMainMessageLoopRunImpl. spvm@chromium.org etienneb@chromium.org Time from application start to renderer run loop start. Application start is a time recorded as early as possible in renderer process startup. Application start is at the start of the renderer process' chrome.exe:main, before chrome.dll is loaded. This metric is only recorded on Windows, and is recorded every time a renderer process starts its run loop, meaning that many instances of this metric will be recorded throughout one execution of the browser. spvm@chromium.org etienneb@chromium.org Time from when ChromeMain in the renderer process was entered to when the renderer run loop was started. This metric is only recorded on Windows, and is recorded every time a renderer process starts its run loop, meaning that many instances of this metric will be recorded throughout one execution of the browser. spvm@chromium.org etienneb@chromium.org Time from when the renderer process was created (CreateProcess call) to when the renderer run loop is started. This metric is only recorded on Windows, and is recorded every time a renderer process starts its run loop, meaning that many instances of this metric will be recorded throughout one execution of the browser. olivierrobin@chromium.org bling-pandamonium@google.com The external application requesting showing the default browser settings. Logged when the command is received from the external application. Histogram only for iOS. Warning: This histogram expired in 2023 and was re-enabled in M153. hidehiko@chromium.org junis@google.com cros-sw-perf+metrics@google.com The amount of time that elapsed during StartupBrowserCreator::LaunchBrowser(). dgn@chromium.org chrome-signin-team@google.com Whether a chrome://welcome page requested from startup tabs has been skipped. Logged on first runs where that page is included in the startup tabs, usually provided by installers in the initial_preferences files. Only the positive value is logged, the histogram's purpose is to verify the reduction in usage of this configuration. chrisha@chromium.org fdoray@chromium.org Indicates whether or not the given startup was warm, cold or unable to be determined. This is based off observing the number of hard faults that occur during startup prior to Startup.BrowserMessageLoopStartTime. The threshold for cold startup was updated Jan 2020, a bump in the metric is expected. olivierrobin@chromium.org justincohen@chromium.org [IOS] The duration between the call to main and the call to [UIApplicationDelegate didFinishLaunching:]. Recorded when first scene is becomes active. olivierrobin@chromium.org justincohen@chromium.org [IOS] The duration between the call to main and the call to the first scene connection. Recorded when first scene is becomes active. spvm@chromium.org fdoray@chromium.org etienneb@chromium.org Time that it took to call base::PreReadFile() during main DLL initialization. Only recorded on Windows. Recorded once on {Process} process startup, as early as possible, but only if base::PreReadFile() was called.