mmandlik@google.com chromeos-bt-platform-sw-core@google.com Records the outcome of bluetooth profile connection request to a remote device. This helps to understand the percentage of successful profile connections against failures and the causes of failures. {BlueZPerProfileResult} mmandlik@google.com chromeos-bt-platform-sw-core@google.com Records the outcome of bluetooth profile probing while pairing with a remote device. This helps to understand the percentage of successful profile probing against failures and the causes of failures. {BlueZPerProfileResult} mcchou@chromium.org chromeos-bt-platform-sw-core@google.com This is specific to Chrome OS. Records the reason of Bluetooth disconnection between the local device and the remote Bluetooth device. This helps us better understand the initiator of disconnection request. mcchou@chromium.org chromeos-bt-platform-sw-core@google.com This is specific to Chrome OS. Records the outcomes of advertisement registration. This helps us better understand the persentage of successful advertisements against failures and the causes of failures. mcchou@chromium.org chromeos-bt-platform-sw-core@google.com This is specific to Chrome OS. Records the outcomes of connection requests to remote devices. This helps us better understand the persentage of successful connections against failures and the causes of failures. mcchou@chromium.org chromeos-bt-platform-sw-core@google.com This is specific to Chrome OS. Records the outcomes of pairing with remote devices. This helps us better understand the persentage of successful pairing against failures and the causes of failures. mcchou@chromium.org chromeos-bt-platform-sw-core@google.com This is specific to Chrome OS. Records the duration when the local device is performing Bluetooth advertisment and discoverable as a Bluetooth Low Energy device by other devices. This helps us better understand the amount of successful advertisment sessions and the duration. mcchou@chromium.org chromeos-bt-platform-sw-core@google.com This is specific to Chrome OS. Records the duration when the local device is discoverable by other devices as a Bluetooth classic device. This helps us better understand the amount of requests to expose the local device as a Bluetooth classic device and the duration. mcchou@chromium.org chromeos-bt-platform-sw-core@google.com This is specific to Chrome OS. Records the duration for the local device to perform device discovery. This helps us better understand the amount of device discovery request and the duration for users to find the target device. mcchou@chromium.org chromeos-bt-platform-sw-core@google.com This is specific to Chrome OS. Records the duration taken to finish a successful pairing between the local device and a remote Bluetooth device. This helps us better understand the latency of completing Bluetooth pairing. mcchou@chromium.org chromeos-bt-platform-sw-core@google.com This is specific to Chrome OS. Records the duration taken to finish a successful connection between the local device and a remote Bluetooth device. This helps us better understand the latency of connecting to a Bluetooth device. mcchou@chromium.org chromeos-bt-platform-sw-core@google.com This is specific to Chrome OS. Records the types of device discovery performed by the local device. This helps us better understand the most common type of device discovery performed. mcchou@chromium.org chromeos-bt-platform-sw-core@google.com This is specific to Chrome OS. Records the types of discovered devices in terms of Bluetooth classic, Bluetooth low energy and Dual-mode supports. This helps us better understand the persentage of Bluetooth devices in terms of type. hidehiko@chromium.org junis@google.com cros-sw-perf@google.com Time from TPMOwn-Start BootTime event until BrowserLaunched BootTime event during the user login on Chrome OS. hidehiko@chromium.org junis@google.com cros-sw-perf@google.com cros-oac@google.com Time from chrome binary exec to login UI ready on Chrome OS. This is recorded from the platform side after receiving "login-ui-visible" event on the platform side in the send-boot-metrics.conf script. Warning: this histogram was expired from M83 to M105; data may be missing. takayas@google.com uekawa@google.com Time from chrome binary exec to login UI ready on ChromeOS. This variant will only track the time taken on {Type}. This is recorded from the platform side after send-boot-metrics.conf script receives login-ui-visible event at the end of the boot. The identification of boot type and actual recording is done by the send-boot-metrics.sh script. briannorris@chromium.org ctshao@google.com alemate@chromium.org baseos-perf@google.com Time from power on to kernel start (Chrome OS). Warning: this histogram was expired from M83 to M105; data may be missing. takayas@google.com uekawa@google.com Time from power on to kernel start (ChromeOS). This variant will only track the time taken on {Type}. This is recorded from the platform side after send-boot-metrics.conf script receives login-ui-visible event at the end of the boot. The identification of boot type and actual recording is done by the send-boot-metrics.sh script. briannorris@chromium.org ctshao@google.com alemate@chromium.org baseos-perf@google.com Time from kernel start to system code being called (Chrome OS). Warning: this histogram was expired from M83 to M105; data may be missing. takayas@google.com uekawa@google.com Time from kernel start to system code being called (ChromeOS). This variant will only track the time taken on {Type}. This is recorded from the platform side after send-boot-metrics.conf script receives login-ui-visible event at the end of the boot. The identification of boot type and actual recording is done by the send-boot-metrics.sh script. antrim@chromium.org hidehiko@chromium.org junis@google.com cros-oac@chromium.org Time from the moment sign in authentication is started until the post login animation finishes. (Chrome OS). hidehiko@chromium.org junis@google.com cros-sw-perf@google.com Chrome OS: The time it takes from when sign-in authentication ends to when the login animation finishes. This marks the end of the login process, as the user's session should be usable at this point. This does not replace the BootTime.Login2 histogram. Warning: this does not include the cryptohome authentication period, unlike BootTime.Login2. TODO(b/323098858): deprecate this with Login4, once we have confirmed the compositor animation waiting time is negligible. hidehiko@chromium.org junis@google.com cros-sw-perf@google.com Chrome OS: The time it takes from when sign-in authentication ends to when the login finishes. This marks the end of the login process, as the user's session should be usable at this point. This is very close to BootTime.Login3, but animation part is not included. The purpose is to make sure animation waiting part is negligible by comparing to BootTime.Login3. Warning: this does not include the cryptohome authentication period, unlike BootTime.Login2. TODO(b/323098858): deprecate this with Login3, once we have confirmed the compositor animation waiting time is negligible. hidehiko@chromium.org junis@google.com cros-sw-perf@google.com Time from the LoginStarted BootTime event until OnAuthSuccess event received. briannorris@chromium.org ctshao@google.com alemate@chromium.org baseos-perf@google.com Time from system code being called to starting Chrome (Chrome OS). Warning: this histogram was expired from M83 to M105; data may be missing. takayas@google.com uekawa@google.com Time from system code being called to starting Chrome (ChromeOS). This variant will only track the time taken on {Type}. This is recorded from the platform side after send-boot-metrics.conf script receives login-ui-visible event at the end of the boot. The identification of boot type and actual recording is done by the send-boot-metrics.sh script. takayas@google.com uekawa@google.com cros-sw-perf@google.com cros-oac@google.com Time from power on to login UI ready on Chrome OS. This is recorded from the platform side after receiving "login-ui-visible" event on the platform side in the send-boot-metrics.conf script. Warning: this histogram was expired from 2022-04-03 to M105; data may be missing. Warning: this histogram is capped at 20 seconds and is not correctly representing longer end of boot time. takayas@google.com uekawa@google.com Time from power on to login UI ready on ChromeOS. This variant will only track the time taken on {Type}. This is recorded from the platform side after send-boot-metrics.conf script receives login-ui-visible event at the end of the boot. The identification of boot type and actual recording is done by the send-boot-metrics.sh script. hidehiko@chromium.org junis@google.com cros-sw-perf@google.com Time from the UserProfileGotten BootTime event until TPM ownershp check starts during the user login on Chrome OS. hidehiko@chromium.org junis@google.com cros-sw-perf@google.com Time from the AuthSuccess BootTime event until user profile loaded during the user login on Chrome OS. Usually it's time spent on user profile loading and parsing. eustas@chromium.org Compressed/Decompressed size ratio. victortan@chromium.org miketaylr@chromium.org katabolism-finch@google.com Emitted on two related events: First, when an request that is eligable to be restarted receives an ACCEPT_CH HTTP2/HTTP3 frame via a TLS connection with the relevent ALPS setting. Next, if that frame causes that request to be restarted. victortan@chromium.org miketaylr@chromium.org katabolism-finch@google.com Count of requests restarted because of the Critical-CH response header. victortan@chromium.org miketaylr@chromium.org katabolism-finch@google.com The latency (in microseconds) to fetch the client hints for a given origin from the Accept-CH cache for {OperationType}. victortan@chromium.org miketaylr@chromium.org katabolism-finch@google.com The latency (in milliseconds) to store the client hints for a given origin in the Accept-CH cache. victortan@chromium.org katabolism-finch@google.com Count of events when the client hints needs to be persisted to the disk by the browser. Collected while navigation responses are being processed. victortan@chromium.org katabolism-finch@google.com Count of client hints that need to be persisted to the disk. Recorded by the renderer. Collected while navigation responses are being processed. pbirk@chromium.org src/android_webview/OWNERS src/components/component_updater/android/OWNERS Records {Component} component loading success, or the failure reason if the component loading fails using the EmbeddedComponentLoader. Note that success here just means that the component has been fetched successfully from the components provider service. However, this doesn't neccessary mean that the component will be then loaded successfully in the system by its respective ComponentLoaderPolicy implementation. sorin@chromium.org src/components/component_updater/OWNERS The number of times the component updater called UpdateClient::Install or UpdateClient::Update. These correspond to the number of manual component update checks performed as a result of a user action, and the number of automated component update checks. Warning: this histogram was expired from 2022-12-20 to 2023-12-04; data may be missing. wanghaifan@google.com cros-demo-mode-eng@google.com src/components/component_updater/OWNERS Chrome OS only. The installation result of the cros component manager. marwant@google.com src/chrome/browser/component_updater/OWNERS Counts the different reasons/ways the platform runtime component got installed: either on startup due to being missing, or on startup due to being stale, or via the background updater process. quarz@chromium.org src/chrome/common/platform_runtime/OWNERS Counts the different outcomes when processing request headers for integrity checks. paugomez@chromium.org danft@chromium.org mardelpi@chromium.org The error code for a failed on-demand update of a Translate Kit language pack component. Recorded when a user action requires an on-device translation for a language pair for which the language pack is not yet installed. paugomez@chromium.org danft@chromium.org mardelpi@chromium.org Chrome OS only. The error code for a failed mount of the Translate Kit component. This is recorded when the component is installed but mounting it via the ImageLoaderClient fails. Can occur as part of the component installation process the first time a user needs on device translation and the component is not yet installed. paugomez@chromium.org danft@chromium.org mardelpi@chromium.org The error code for a failed on-demand update of the Translate Kit component. Recorded when an on-demand update of the main TranslateKit component fails. This is a one time event indirectly triggered by a user action. (not periodic or on startup) sorin@chromium.org src/components/component_updater/OWNERS The result of an install or an update check. sorin@chromium.org src/components/component_updater/OWNERS The result of an install or an update check. sorin@chromium.org src/components/component_updater/OWNERS Time to complete an Install or an Update component update call. Warning: this histogram was expired from 2022-12-20 to 2023-12-04; data may be missing. sisidovski@chromium.org chrome-loading@google.com Records whether a document's declarative performance observer exceeded its quota and dropped entries. Recorded at the end of the document's lifecycle (session end). sisidovski@chromium.org chrome-loading@google.com Records the peak buffer size (in KB) accumulated by a document's declarative performance observer. Recorded at the end of the document's lifecycle (session end). greengrape@google.com iwa-team@google.com How often tcp socket opening finishes with a network failure. greengrape@google.com iwa-team@google.com How often tcp socket readable stream is errored. greengrape@google.com iwa-team@google.com How often tcp server socket opening finishes with a network failure. greengrape@google.com iwa-team@google.com How often tcp server socket readable stream is errored. greengrape@google.com iwa-team@google.com How often tcp socket writable stream is errored. greengrape@google.com iwa-team@google.com How often udp socket opening finishes with a network failure. greengrape@google.com iwa-team@google.com How often udp socket readable stream is errored. greengrape@google.com iwa-team@google.com How often udp socket writable stream is errored. panicker@chromium.org chikamune@chromium.org Records result of invoking beforeunload handler, that determines whether to show the dialog. Warning: this histogram was expired from M77 to M108; data may be missing. sullivan@chromium.org chikamune@chromium.org Milliseconds spent in beforeunload dialog. Does not include time to process beforeunload event in JavaScript. Recorded immediately after closing dialog, upon user confirmation to navigate away from the page. Warning: this histogram was expired from 2020-09-05 to M108, and from 2023-10-01 to M144; data may be missing. bmgordon@chromium.org project-bolton@google.com Chrome OS document scan metric that tracks which SANE backend (effectively a scanner driver) was used when a scan failed. rishabhagr@google.com project-bolton@google.com Chrome OS document scan metric that tracks the stage at which the scan failed. rishabhagr@google.com project-bolton@google.com Chrome OS document scan metric that tracks the reason of a scan failure. bmgordon@chromium.org project-bolton@google.com Chrome OS document scan metric that tracks which SANE backend (effectively a scanner driver) that a user requested to use for a scan. bmgordon@chromium.org project-bolton@google.com Chrome OS document scan metric that tracks which SANE backend (effectively a scanner driver) was used when a scan succeeded. grt@chromium.org ydago@chromium.org Indicates whether or not restoring a snapshot of the user data dir succeeded or failed. simmonsjosh@google.com src/ui/file_manager/OWNERS Tracks whether the push notification request is registered correctly for Drive. Recorded when the push notification manager is initialized. hiroh@chromium.org chromeos-gfx-video@google.com Number of bits per channel described by a parsed EDID blob. This UMA is recorded whenever the color space is extracted from an EDID blob. Warning: this histogram was expired from 2022-01-03 to 2023-05-17; data may be missing. Warning: this histogram was expired from 2024-05-16 to 2025-09-01; data may be missing. hiroh@chromium.org chromeos-gfx-video@google.com Whether an EDID blob was detected. This UMA is recorded whenever we attempt to parse the EDID from a display. Warning: this histogram was expired from 2022-01-03 to 2023-05-17; data may be missing. Warning: this histogram was expired from 2024-05-16 to 2025-09-01; data may be missing. hiroh@chromium.org chromeos-gfx-video@google.com Whether a EDID blob contained an HDR transfer function (e.g. SMPT SE2084 or HLG). This UMA is recorded whenever the color space is extracted from an EDID blob. Warning: this histogram was expired from 2022-01-03 to 2023-05-17; data may be missing. andrescj@chromium.org sashamcintosh@chromium.org chromeos-gfx@google.com When attempting to get the color space from an EDID blob, whether the sanity checks passed (and if not, which check failed). This UMA is recorded whenever the color space is extracted from an EDID blob. Expired in January 2022, and revived in June 2023 (M117). Data collected between those dates may be incomplete. crisrael@google.com jonmann@chromium.org chromeos-cross-device-eng@google.com This metric tracks the time it takes from the phone becoming connected to the Chromebook and sending the PhoneStatusSnapshot proto until the phone sends over the entire apps list via the AppListUpdate proto. Emitted after the app stream launcher loads the app list. crisrael@google.com jonmann@chromium.org chromeos-cross-device-eng@google.com This metric logs where the Eche app was launched from. The metric is emmited when the eche app is launched. crisrael@google.com exo-core-eng@google.com chromeos-cross-device-eng@google.com The duration of time the phone is in the state connected to eche signaling service, and becomes disconnected. crisrael@google.com exo-core-eng@google.com chromeos-cross-device-eng@google.com Measures Eche connection success rate. This is recorded at the end of each connection attempt whether it fails or succeeds and the failure bucket is broken down to more specific segments in Eche.Connection.Result.FailureReason jonmann@chromium.org chromeos-cross-device-eng@google.com The reason for which the connection attempt to the phone has failed. This is a breakdown of the failure bucket of Eche.Connection.Result and is recorded at the time a connection attempt fails. crisrael@google.com exo-core-eng@google.com chromeos-cross-device-eng@google.com The duration of time the phone is in the state connecting to eche signaling service, and becomes connected. jonmann@chromium.org chromeos-cross-device-eng@google.com Indicates the feature state of the Exo feature. This metric is emitted to at the creation of the user session (when the user logs in), when any multi-device feature state changes, and every 30 minutes. jonmann@google.com nayebi@google.com chromeos-cross-device-eng@google.com Failure reason emitted by EcheSignaler on background connect attempt failures. jonmann@google.com nayebi@google.com chromeos-cross-device-eng@google.com Emitted on success or failure of a background network connection attempt. Triggered when Phone Hub first connects, and on each bubble opened event. crisrael@google.com exo-core-eng@google.com samchiu@google.com Events logged the user action in the Eche onboarding. Recorded when users start Eche onboarding and grant the permission that onboarding needs. crisrael@google.com exo-core-eng@google.com chromeos-cross-device-eng@google.com Events logged in the Eche stream state. Records when a stream is started and initialized after the user interacts with a PhoneHub notification or the recent app by clicking it to launch the app streaming window. crisrael@google.com exo-core-eng@google.com chromeos-cross-device-eng@google.com Events logged the root cause of Eche connection failure. Records when signaling timeout on EcheSignaler or the tablet mode check on EcheTray. crisrael@google.com exo-core-eng@google.com chromeos-cross-device-eng@google.com Records the elapsed time from when the stream is initializing to when the stream is closed before the stream doesn't started. Fires during the process of closing Eche streaming when the stream doesn't start. It is not sent on a successful connection attempt. pushi@google.com jonmann@google.com chromeos-cross-device-eng@google.com Events logged in the Eche stream state. Records when a stream is initialized and started after the user clicks on an app from full app list (Launcher) to launch the app streaming window. pushi@google.com jonmann@google.com chromeos-cross-device-eng@google.com Events logged in the Eche stream state. Records when a stream is initialized and started after the user clicks on a PhoneHub notification to launch the app streaming window. pushi@google.com jonmann@google.com chromeos-cross-device-eng@google.com Events logged the root cause of Eche connection failure when triggered from a notification and failed in last network connection check. Records when signaling timeout on EcheSignaler or the tablet mode check on EcheTray. Separate from Eche.StreamEvent.ConnectionFail. pushi@google.com jonmann@google.com chromeos-cross-device-eng@google.com Records the success rate of app streaming when triggered from notificaiton and failed in last network connection check. Recorded when the stream is initialized in EcheTray or when it starts in EcheStreamStatusChangeHandler. Separate from Eche.StreamEvent. pushi@google.com jonmann@google.com chromeos-cross-device-eng@google.com Events logged in the Eche stream state. Records when a stream is initialized and started after the user clicks on an app from recent app list to launch the app streaming window. crisrael@google.com jonmann@chromium.org chromeos-cross-device-eng@google.com This metric tracks the number of unique apps the user attempts to launch an app stream. Emitted when the app stream is launched and the app has not been launched in the current session. longbowei@google.com xiangdongkong@google.com cros-device-enablement@google.com Records whether users allow Google to contact them about the issues. Fires when feedback report is being sent. longbowei@google.com xiangdongkong@google.com cros-device-enablement@google.com Record the length of description in the textbox. Fires when the feedback report is being sent. xiangdongkong@google.com cros-device-enablement@google.com Records the elapsed time from the start of fetching Debugd logs via the GetBigFeedbackLogs dbus method to when the data has been retrieved. Fires during the process of sending a feedback report on Chrome OS, or when the user previews the system logs from the feedback app on Chrome OS. GetBigFeedbackLogs is the dbus method used. longbowei@google.com xiangdongkong@google.com cros-device-enablement@google.com Records a summary of the actions the user took before exiting the app. Fires when user closes the feedback app, case includes: User quits on search page after clicking some help contents; User quits on search page without clicking some help contents; User closes on search page because no help content is shown(Offline or Search is down); User closes on share data page after clicking help content; User closes on share data page without clicking help content; User submits feedback after clicking the help content; User submits feedback without clicking the help content. xiangdongkong@google.com cros-device-enablement@google.com Records the number of logs with empty data retrieved from debugd for feedback reports. Fires during the process of sending a feedback report on Chrome OS, or when the user previews the system logs from the feedback app on Chrome OS. xiangdongkong@google.com cros-device-enablement@google.com Records the number of logs with not available data retrieved from debugd for feedback reports. Fires during the process of sending a feedback report on Chrome OS, or when the user previews the system logs from the feedback app on Chrome OS. xiangdongkong@google.com cros-device-enablement@google.com Records the number of logs with data not empty or not available retrieved from debugd for feedback reports. Fires during the process of sending a feedback report on Chrome OS, or when the user previews the system logs from the feedback app on Chrome OS. xiangdongkong@google.com cros-device-enablement@google.com Records the success status of fetching the feedback logs via debus method GetBigFeedbackLogs. Fires during the process of sending a feedback report on Chrome OS, or when the user previews the system logs from the feedback app on Chrome OS. xiangdongkong@google.com cros-device-enablement@google.com Records the different results of fetching the feedback logs via debus method GetFeedbackLogsV2. Fires during the process of sending a feedback report on Chrome OS, or when the user previews the system logs from the feedback app on Chrome OS. longbowei@google.com xiangdongkong@google.com cros-device-enablement@google.com Record the outcome of checking help contents. Fires when user leaves the search page by clicking continue or by clicking x on top right to close the app. longbowei@google.com xiangdongkong@google.com cros-device-enablement@google.com Records the number of help content results returned in each search. Fires when user clicks and views the help content on search page. longbowei@google.com xiangdongkong@google.com cros-device-enablement@google.com Records whether the email is included when the feedback report is submitted. Fires when user's feedback report is being sent. longbowei@google.com xiangdongkong@google.com cros-device-enablement@google.com Records whether attached file is included when the feedback report is submitted. Fires when user's feedback report is being sent. longbowei@google.com xiangdongkong@google.com cros-device-enablement@google.com Records whether the screenshot is included when the feedback report is submitted. Fires when a user's feedback report is successfully sent. longbowei@google.com xiangdongkong@google.com cros-device-enablement@google.com Records whether the system and information is included when the feedback report is submitted. Fires when a user's feedback report is being sent. longbowei@google.com xiangdongkong@google.com cros-device-enablement@google.com Records whether the page url is included when the feedback report is submitted. Fires when user's feedback report is being sent. longbowei@google.com xiangdongkong@google.com cros-device-enablement@google.com Records the duration that the Feedback App is open. Emitted when the app is closed. longbowei@google.com xiangdongkong@google.com cros-device-enablement@google.com Records the first action that the users take after sending feedback. Fires on the first action taken on post submit page after the user has sent the feedback. longbowei@google.com xiangdongkong@google.com cros-device-enablement@google.com Records the duration that the Feedback App is open on {FeedbackAppPage} page. Fires when the user closes the app or starts new report after feedback report has been sent. longbowei@google.com xiangdongkong@google.com cros-device-enablement@google.com Record number of times the user viewed the help content. Fires when user clicks help content on search page. longbowei@google.com xiangdongkong@google.com cros-device-enablement@google.com Record number of times the user viewed the attached image. Fires when user clicks the thumbnail and views the larger image. longbowei@google.com xiangdongkong@google.com cros-device-enablement@google.com Record number of times the user viewed the metrics. Fires when user clicks metrics link and views metrics. longbowei@google.com xiangdongkong@google.com cros-device-enablement@google.com Record number of times the user viewed the screenshot. Fires when user clicks the thumbnail on and views the larger screenshot. longbowei@google.com xiangdongkong@google.com cros-device-enablement@google.com Record number of times the user viewed the system and app information. Fires when system and app info link is clicked. xiangdongkong@google.com fernandex@google.com cros-device-enablement@google.com Records the elapsed time from the start of fetching system information to when the data has been retrieved. Fires during the process of sending a feedback report on Chrome (Desktop + Android) or Chrome OS. xiangdongkong@google.com fernandex@google.com cros-device-enablement@google.com Records the elapsed time from when the feedback app window is opened to when the backend receives the send report request submitted by a user. Fires during the process of sending a feedback report on Chrome (Desktop + Android) or Chrome OS. xiangdongkong@google.com cros-device-enablement@google.com Records the elapsed time from when the backend receives the send report request submitted by a user to when it starts to send confirmation back to the frontend. Fires during the process of sending a feedback report on Chrome or Chrome OS. xiangdongkong@google.com cros-device-enablement@google.com Records the elapsed time from when the backend receives the send report request submitted by a user and the report has been added to the send queue. Fires during the process of sending a feedback report on Chrome or Chrome OS. sauski@google.com msramek@chromium.org Records the first reason why the Happiness Tracking Surveys (HaTS) bubble was or was not shown. While the request to show may not meet multiple criteria, the first criterion is reported here. ravjit@google.com msramek@google.com Recorded whenever a Happiness Tracking Survey (HaTS) survey is completed. Only recorded the survey is fully completed. zhouzj@google.com msramek@google.com Records the responses for HaTS questions. Emitted during the lifecycle of a survey and when a user answers any question on a HaTS survey. jlebel@chromium.org chrome-regionalcapabilities@google.com Recorded when the user attempts to submit feedback, but feedback submission is not allowed for that user. This counts cases where the feedback entry point was available, but the feedback dialog was blocked. nikj@google.com dpchromeos-core-eng@google.com Records how many times PIIs are redacted by the Client side log redaction tool. rohkap@google.com dpchromeos-core-eng@google.com Records which caller invoked the redaction tool. This helps us determine where the most redactions are happening and so places emitting most PII in logs. cschlosser@chromium.org dpchromeos-core-eng@google.com The redaction tool can be used to redact potential PII on the client side before logs and other data is sent to servers. This histogram is recorded when attempting to verify if a matched string is a credit card. Since we don't have guaranteed context for credit cards in our logs, unlike e.g. shill log format, we have to do apply some heuristic. There are several steps where the validation could detect a false positive and we want to measure how effective these mechanisms are. cschlosser@chromium.org dpchromeos-core-eng@google.com Records how many milliseconds elapsed while redacting the input text by the redaction_tool. This metric is recorded after each redaction (JS error or feedback report). This metric should be a rough control so we aren't running a very long time in the background after a report. cschlosser@chromium.org dpchromeos-core-eng@google.com Records how many milliseconds elapsed while redacting the logs of a crash inside ChromeOS's crash_reporter. This metric is recorded for each crash that has text logs that need redaction, at the time the crash happens. This metric should be a rough control so we aren't running a very long time after a crash and the user has to wait for the frozen screen to disappear. xiangdongkong@google.com cros-device-enablement@google.com Records whether the user is online when the feedback report was submitted. xiangdongkong@google.com cros-device-enablement@google.com Records the feedback report sending states to help track the success rate of feedback report offline submission. afakhry@chromium.org cros-device-enablement@google.com Records the source that requested showing the feedback app. Only recorded if feedback submission is allowed. This histogram is only recorded on desktop platforms (Windows, macOS, Linux, ChromeOS). For iOS, see IOS.Feedback.ReportAnIssue.Displayed and IOS.Feedback.ReportAnIssue.NotDisplayed. skrakowi@google.com chrome-counter-abuse-alerts@google.com Records the associated feature area when the Trust and Safety sentiment service detects that the user has performed a trigger action. This is recorded before the associated probability check and will be used to verify the infrastructure of newly integrated feature areas. We will remove this histogram once we verify the implementation. sauski@google.com chrome-hats-eng@google.com Records the associated feature area when the Trust and Safety Sentiment service requests a survey be shown from the HaTS service. sauski@google.com chrome-hats-eng@google.com Records the associated feature area when the Trust and Safety sentiment service detects that the user has performed a trigger action. This is recorded after the associated probability check. mych@chromium.org chrome-bfcache@google.com Recorded the duration of a fetch keepalive request between when such request is constructed by a blink::FetchManager and when the blink::FetchManager {RequestState} This does not log for non-fetch types of keepalive request, meaning that beacons or pings are all excluded. Note that as this is from the view of a renderer, it contains only partial metrics when fetch keepalive in-browser is enabled. mych@chromium.org chrome-bfcache@google.com Recorded the time a fetch keepalive request stays alive after its renderer has detached, starting from when a blink::ThreadableLoader::Detach() of the keepalive request is called, and ending with when such ThreadableLoader is cleared. This does not log for non-fetch types of keepalive request, meaning that beacons or pings are all excluded. This is to measure how much time the keepalive in-browser migration is able to save. mych@chromium.org chrome-bfcache@google.com Recorded an entry when a Fetch keepalive request loader in the Network service meets the states defined in the enum, e.g. request created or response received. mych@chromium.org chrome-bfcache@google.com Recorded true when a Fetch keepalive request loader in the browser process is about to shut down and the request loading has been started. mych@chromium.org chrome-bfcache@google.com Recorded true when a Fetch keepalive request loader in the {Process} {RequestState} while the context is already detached. mych@chromium.org chrome-bfcache@google.com Recorded a Fetch keepalive request type every time a request loader of such request in the {Process} {RequestState} mych@chromium.org chrome-bfcache@google.com Records once every time a scheduled FetchLater request is either aborted or started in browser. mych@chromium.org chrome-bfcache@google.com Records true every time {LoaderStatus} mych@chromium.org chrome-bfcache@google.com Records once every time a scheduled FetchLater request is either aborted or activated in renderer. mych@chromium.org chrome-bfcache@google.com Records true every time a new FetchLater request is scheduled by a renderer. It does NOT equal to the total number of JavaScript FetchLater API call, as the latter can be immediately rejected with various JavaScript exceptions. This metric is recorded to compare whether different behavior happens between renderer and browser. This number should be compared with `FetchLater.Browser.Total`, and it should be equal to the sum of `FetchLater.Renderer.Metrics`. wylieb@chromium.org bjfong@google.com Records the end-to-end time taken from receiving a request for suggestions (ExecuteModelAndScheduleNotification) to delivering those suggestions back to the caller. wylieb@chromium.org bjfong@google.com Records the status of attempting to execute the Finds model and schedule a notification. Recorded when the FindsService attempts to fetch suggestions based on themes derived from the user's history. It tracks successes and various failure reasons like service unavailability, empty history, or cooldown restrictions. atharvmaan@chromium.org chrome-desktop-ui-waterloo@google.com Tracks the success or failure of the automatic bookmark import from the Initial Preferences file. This is a one-time import that occurs during the user's First Run experience. jlebel@chromium.org olivierrobin@chromium.org Counts the number of times First Run experience was triggered by another application launching Chrome. This metric measures the effectiveness of Smart App Banner promotions on installation of Chrome. johntlee@chromium.org dpapad@chromium.org Records when a user interacted with the Google Apps new user experience. We record both accept and reject but are not recording when a user ignored the prompt completely. Users can ignore this prompt by closing the tab or navigating away, we record when the prompt is shown. Warning: this histogram was expired from M76 to M100; data may be missing. scottchen@chromium.org Records when a user interacted with the landing page of the onboarding process. We record that the page was seen and what action the user took. johntlee@chromium.org dpapad@chromium.org Records when a user interacts with the NTP Backgrounds new user experience. We record the number of times the page is seen, how they interacted with the page (i.e. interacted with the options and buttons), and through what method they leave the page (i.e, confirm, cancel, neither). The new user experience should only be shown once to new profiles. johntlee@chromium.org dpapad@chromium.org Records when a user interacted with the set default page of the onboarding process. We record that the page was seen and what action the user took. jlebel@chromium.org chrome-signin-team@google.com Records the result of an attempt to create the first run sentinel file. On iOS, file system errors are detailed further by the FirstRun.Sentinel.CreatedFileError histogram. jlebel@chromium.org chrome-signin-team@google.com File error when the sentinel file was not written. jlebel@chromium.org msarda@chromium.org chrome-signin-team@google.com Result of the sign in flow during first run on iOS. tinazwang@chromium.org bling-get-started@google.com When Chrome is opened for the first time, the first run (onboarding) UI will be shown. Metircs will be recorded in different first run stages such as when first run experience is started, and when first run experience is completed. justincohen@chromium.org olivierrobin@chromium.org WARNING: The list of actions used to identify new tasks hasn't been attentively updated for several years (as of 2017). Some actions that should likely be considered new tasks are probably missing. Take this histogram with a grain of salt. Was expired for M85, M86. The amount of time (in seconds) that the app was in the background before the user started it {ActionType}. {DeviceType} justincohen@chromium.org olivierrobin@chromium.org WARNING: The list of actions used to identify new tasks hasn't been attentively updated for several years (as of 2017). Some actions that should likely be considered new tasks are probably missing. Take this histogram with a grain of salt. Was expired for M77-M86. On handsets, the type of the first user action performed after the app was started or unbackgrounded. justincohen@chromium.org olivierrobin@chromium.org WARNING: The list of actions used to identify new tasks hasn't been attentively updated for several years (as of 2017). Some actions that should likely be considered new tasks are probably missing. Take this histogram with a grain of salt. Was expired for M82-M86. On tablets, the type of the first user action performed after the app was started or unbackgrounded. droger@chromium.org msarda@chromium.org Reports the network error code for requests to the ListAccounts Gaia endpoint. msarda@chromium.org droger@chromium.org chrome-signin-team@google.com URLFetcher response codes for OAuth2AccessToken. Positive values are HTTP status codes, negative values are network error codes. Recorded on responses to OAuth access token requests. msarda@chromium.org droger@chromium.org chrome-signin-team@google.com Records the result of the Oauth2 access token request when a response is received from the LSO server except in net failure cases. In error cases, it records the error code in the response body. robpitkin@google.com deviceapi-team@google.com Records the data fetcher source when a new gamepad is detected and assigned a device slot. robpitkin@google.com deviceapi-team@google.com Records an enumeration value identifying the data fetcher that ignored a device because it is already handled by a more specialized data fetcher. mattreynolds@chromium.org deviceapi-team@google.com Records an integer value that can be used to identify a connected gamepad device. The value is constructed from the 16-bit vendor ID in the high-order bytes and the 16-bit product ID in the low-order bytes, then cast to a 32-bit signed integer. The GamepadVendorProduct enum lists IDs for several popular gamepads but is incomplete. To identify a device not included in the enum, convert back to the vendor/product IDs and look up the human-friendly product name in go/gamepad-ids. This histogram records a new entry when a device with a vendor and product ID matching a known gaming input device is detected during Gamepad API enumeration. robpitkin@google.com mattreynolds@chromium.org The outcome of a gamepad connection attempt in the macOS GameController data fetcher. Recorded exactly once per recognized connection attempt. robpitkin@google.com mattreynolds@chromium.org The outcome of a gamepad connection attempt in the macOS GamepadPlatform data fetcher. Recorded exactly once per recognized connection attempt. robpitkin@google.com mattreynolds@chromium.org The outcome of a gamepad connection attempt in the macOS Xbox (USB) data fetcher. Recorded exactly once per recognized connection attempt. mattreynolds@google.com gabrielbrito@microsoft.com Records the elapsed time in microseconds between the gamepad's last hardware update (as reported by the gamepad timestamp) and the moment before the gamepadrawinputchanged event starts dispatching. This measures the total end-to-end delay from input to event delivery. This is only recorded on clients with high-resolution clocks. mattreynolds@google.com gabrielbrito@microsoft.com Records the elapsed time in microseconds spent dispatching a single gamepadrawinputchanged event, measured from just before DispatchEvent is called to just after it returns. This reflects the time taken to run all registered event listeners for the event. This is only recorded on clients with high-resolution clocks. mattreynolds@google.com reillyg@google.com Counts the number of read contentions on the gamepad SeqLock. This is sampled at 60Hz when the gamepad API is active for the page. It is capped at a maximum of 10, after which the read fails. mattreynolds@chromium.org deviceapi-team@google.com Records an enumeration value identifying the active data fetcher when a fetcher enumerates a device that is not on the list of known gamepads, but is recognized as a gamepad by the fetcher. robpitkin@google.com mattreynolds@google.com deviceapi-team@google.com Records the result of opening a USB Xbox gamepad on macOS. This helps diagnose issues where Chrome fails to get exclusive access to the device. mattreynolds@google.com reillyg@google.com Whether the browser sent a valid shared memory handle to the renderer. mattreynolds@chromium.org gabrielbrito@microsoft.com The HRESULT returned by GameInputCreate in the Windows GameInput data fetcher. Recorded once when the data fetcher is added to the gamepad provider and attempts to create the GameInput instance. mattreynolds@chromium.org gabrielbrito@microsoft.com The outcome of a gamepad added event in the Windows GameInput data fetcher. Recorded once per gamepad connection attempt. mattreynolds@chromium.org gabrielbrito@microsoft.com Recorded each time GetCurrentReading fails for a connected gamepad in the Windows GameInput data fetcher. mattreynolds@chromium.org gabrielbrito@microsoft.com Recorded each time the guide button is pressed on a gamepad connected via the Windows GameInput data fetcher. mattreynolds@chromium.org gabrielbrito@microsoft.com Whether a newly connected gamepad supports trigger rumble in the Windows GameInput data fetcher. Recorded once per successful gamepad connection. mattreynolds@chromium.org gabrielbrito@microsoft.com The outcome of GameInput API initialization in the Windows GameInput data fetcher. Recorded once when the data fetcher is added to the gamepad provider. sashamcintosh@chromium.org chromeos-gfx@chromium.org The number of displays present right after the user has attached or detached a new display. Excludes mirrored displays, but includes sleeping displays. sashamcintosh@chromium.org chromeos-gfx@chromium.org The number of displays present at start up. Excludes mirrored displays, but includes sleeping displays. cassew@google.com media-dev-uma@chromium.org Whether a given display device supports HDR (such that the CSS media query `dynamic-range: high` would resolve as true). Recorded upon browser startup (for every connected display), upon display device connection (for the newly connected display), and upon any change to the color space metric (for the affected display). zmo@chromium.org chrome-gpu-metric-alerts@chromium.org Records a rough estimation of the system total disk space collected in the info collection GPU process, once per UMA ping. chingkang@chromium.org cros-hwsec-userland-eng+uma@google.com The duration of preparation for enrollment in attestation. chingkang@chromium.org cros-hwsec-userland-eng+uma@google.com The result of attestation-related operations on the Chrome OS side. {AttestationOps} robliao@chromium.org gab@chromium.org The importer used on first run Auto Import. Warning: This histogram was expired from 2018-09 to 2023-07; data may be missing. robliao@chromium.org gab@chromium.org The importer used on import from the bookmarks file API. Warning: This histogram was expired from M77 to M117; data may be missing. robliao@chromium.org gab@chromium.org The importer used on import from the chrome://settings/importData UI. Warning: This histogram was expired from 2018-09 to 2023-07; data may be missing. etienneb@chromium.org joenotcharles@google.com The result when ImportantFileWriter moves the temporary file to its final location. Recorded on every write with ImportantFileWriter. If retries were needed, the retry count is recorded in ImportantFile.FileReplaceRetryCount2. {ImportantFileClients} etienneb@chromium.org grt@chromium.org The number of retries needed to successfully move the temporary file to its final location. Zero means that ReplaceFile worked the first time. Ten means that it never succeeded. etienneb@chromium.org joenotcharles@google.com The number of retries needed for ImportantFileWriter to move the temporary file to its final location, succeed or fail. The success or failure of the operation is recorded in ImportantFile.FileReplaceResult. Unlike ImportantFile.FileReplaceRetryCount, this is only logged if a retry is needed. {ImportantFileClients} grt@chromium.org tingshao@microsoft.com The result of attempting to restore a missing important file (e.g. a preferences file) from a leftover temporary file previously written by ImportantFileWriter. Recorded only when the target file is missing at read time, from ImportantFileWriter::RestoreMissingFileIfNeeded(). Note that a "restored" result only means that a leftover temporary file was moved into place. It doesn't mean that data was recovered from that file. {ImportantFileClients} battre@chromium.org gab@chromium.org Time spent in the foreground thread (usually UI thread) to serialize the data to be written into an important file (e.g. serialize JSON string for preferences). For users of ImportantFileWriter that leverage background serialization (e.g. bookmarks), it excludes the time spent on the background thread, and only logs the time spent on the foreground thread. {ImportantFileClients} asvitkine@chromium.org chrome-metrics-team@google.com Size of the serialized data to be written into an important file. Recorded when the file is written. Note: As client suffixes are added the volume of the unsufixed variant will decline. This needs to be taken into account when analyzing overall counts. {ImportantFileClients} wylieb@google.com chrome-collections@google.com Time spent in the background thread to write serialized data into an important file. Recorded when the file is written. Note: As client suffixes are added the volume of the unsufixed variant will decline. This needs to be taken into account when analyzing overall counts. {ImportantFileClients} roagarwal@chromium.org chrome-incognito@google.com Records the action taken by the user on the Incognito clear browsing data dialog. rushans@google.com peter@chromium.org Net error code from a GetToken request. Recorded when URL loading fails. rushans@google.com peter@chromium.org Status code of the outcome of GetToken request. Warning: this histogram was expired from 2023-08-06 to 2023-09-22, and from 2024-02-20 to 2024-05-28; data may be missing. rushans@google.com peter@chromium.org treib@chromium.org Status code of the outcome of GetToken request for Sync invalidations (subtype was "com.google.chrome.sync.invalidations"). asvitkine@chromium.org ntfschr@chromium.org Logs which Chrome flags from about:flags were active on start up. Android WebView supports flags differently than most platforms, see https://chromium.googlesource.com/chromium/src/+/HEAD/android_webview/docs/developer-ui.md for details. calamity@chromium.org davidbienvenu@chromium.org grt@chromium.org The different ways Chrome is launched. This replaces Launch.Modes. Emitted once at startup, when the user launches Chrome to browse the web or launch a Web App. It is not recorded if Chrome is launched in other ways: by the installer, after an update, after a flag change, after an OS update, to install/uninstall/list apps, or in background mode. chikamune@chromium.org chrome-loading@google.com Records whether the network is considered to be slow or not. Recorded on each call of LoadingPredictor::PrepareForPageLoad() function if kSuppressesLoadingPredictorOnSlowNetwork feature is enabled. yyanagisawa@chromium.org chrome-loading@google.com The status of SetLCPPNavigationHint. It is recorded when the kLCPCriticalPathPredictor feature is enabled and MaybeSetLCPPNavigationHint is called. It includes status on not only SetLCPPNavigation failure, but also success for ease of understanding the failure ratio. sophiechang@chromium.org tbansal@chromium.org spelchat@chromium.org chrome-brapp-loading@chromium.org 1457018 The status of when the optimization hints were received by the Loading Predictor. This will be recorded on navigations for which predictions from the Optimization Guide were received. yoichio@chromium.org chrome-loading@chromium.org 1457018 The size, in kilobytes, of the database used for the loading prediction. Values can range from 1KiB to 1GiB. Logged at browser startup and daily. yyanagisawa@chromium.org chrome-loading@google.com The status of SetLCPPNavigationHint. It is recorded when the kLCPCriticalPathPredictor feature is enabled and MaybeSetLCPPNavigationHint is called. It includes status on not only SetLCPPNavigation failure, but also success for ease of understanding the failure ratio. Warning: this histogram was expired from 2024-05-01 to 2024-11-01; data may be missing. chikamune@chromium.org chrome-loading@google.com Measures the elapsed time it takes to read LCPPNavigationHint and attach it to NavigationHandle. Recorded on DidStartNavigatinon or DidRedirectNavigation only when there is hint information. mgiuca@chromium.org Tracks which properties of a Manifest were present when it was parsed. If a property can't be parsed, it will be recorded as not present. These histograms will only be used if the Manifest was correctly fetched and parsed and the parsed manifest is not empty. {ManifestProperties} phillis@chromium.org pwa-team@chromium.org Tracks the result of parsing id field in the Manifest. rakina@chromium.org navigation-dev@chromium.org For each RenderProcessHost, records its time spent between pausing and flushing its IPC channel via Pause() (triggered when the channel is intialized) and Flush() (after the renderer process launched notification is received) respectively. Recorded when the channel gets flushed. rakina@chromium.org navigation-dev@chromium.org For each RenderProcessHost, records its time spent between pausing and flushing its IPC channel via Pause() (triggered when the channel is initialized) and Unpause() (after the renderer process launched notification is received) respectively. Recorded when the channel gets unpaused. rakina@chromium.org navigation-dev@chromium.org For each RenderProcessHost, records its time spent between pausing and flushing its IPC channel via Pause() (triggered when renderer process launch is requested) and Flush() (after the renderer process launched notification is received) respectively. Recorded when the channel gets flushed. rakina@chromium.org navigation-dev@chromium.org For each RenderProcessHost, records its time spent between pausing and flushing its IPC channel via Pause() (triggered when renderer process launch is requested) and Unpause() (after the renderer process launched notification is received) respectively. Recorded when the channel gets unpaused. nafisabedin@google.com pasko@chromium.org bgeffon@chromium.org Measures the time taken to write a channel message to the underlying transport in Mojo. The metric is downsampled to reduce its costs. This is only recorded on clients with high-resolution clocks. amistry@chromium.org bgeffon@chromium.org rockot@google.com The size of a message written to a channel. pasko@chromium.org bgeffon@chromium.org The number queued messages waiting to be written, measured when a channel flush is attempted. amanvr@chromium.org woa-performance@google.com Records the number of sent Mojo IPCs, split per process. Emitted each time a mojo IPC is sent. lizeb@chromium.org rockot@google.com Measures the time taken between an IPCz message serialization until it is deserialized on the other side of the Channel. This metric is downsampled to reduce its cost. This is only recorded on clients with high-resolution clocks. pasko@chromium.org nafisabedin@google.com Measures the time taken to write a channel message to the underlying shared memory ring buffer in ChannelLinux. The metric is downsampled to reduce its costs. siggi@chromium.org rockot@chromium.org The maximal unread message quota used for the lifetime of a Connector. This is sampled for a configurable percentage of Connectors only when the feature MojoRecordUnreadMessageCount is enabled. By default 1% of Connectors are sampled, as there's some overhead involved in enabling the unread message quota on a MessagePipe. See //mojo/public/cpp/bindings/lib/connector.cc. joenotcharles@google.com pasko@chromium.org Logs the result of the AdoptPipe operation whenever mojo::DirectReceiver<T>::Bind() is called. Each kSuccess result will be followed by an asynchronous MergePortals operation, whose result is logged in Mojo.DirectReceiver.MergePortalsResult. Each failure immediately logs kNotAttempted to Mojo.DirectReceiver.MergePortalsResult. joenotcharles@google.com pasko@chromium.org Logs the result of the MergePortals operation whenever mojo::DirectReceiver<T>::Bind() is called. MergePortals happens after an AdoptPipe operation whose result is logged in Mojo.DirectReceiver.AdoptPipeResult. If the AdoptPipe fails, kNotAttempted is logged immediately. Otherwise the MergePortals result is logged when the Mojo message to merge the portals in the local node is processed. So, a difference in counts between this and AdoptPipeResult indicates merges that never completed. lizeb@chromium.org rockot@google.com mthiesse@chromium.org Measures the time taken from the sender calling a mojo interface function to the receiver's implementation getting invoked. Sub-sampled to 1/1000 calls to reduce measurement overhead. Metric is split by receiving thread for some important threads. All other threads are grouped under 'Default'. This is only recorded on clients with high-resolution clocks. pasko@chromium.org nafisabedin@google.com Logs the block size category of a failed shared memory block allocation attempt in an ipcz BufferPool. Logged on every failed block allocation attempt in BufferPool::AllocateBlock. Subsampled to 1/1000. pasko@chromium.org nafisabedin@google.com Logs whether an ipcz BufferPool successfully allocated a fixed-size shared memory block from its block allocator pools. Logged on every block allocation attempt in BufferPool::AllocateBlock. Subsampled to 1/1000. pasko@chromium.org nafisabedin@google.com Logs the block size category of a successful shared memory block allocation attempt in an ipcz BufferPool. Logged on every successful block allocation attempt in BufferPool::AllocateBlock. Subsampled to 1/1000. olivierli@chromium.org joenotcharles@google.com Logs whether mojo managed to allocate shared memory for the SharedMemoryVersionController.. Logged on SharedMemoryVersionController construction. ajgo@chromium.org src/sandbox/policy/win/OWNERS The amount of time spent within ChildProcessLauncher while launching a process. These metrics are being added to measure upcoming changes to sandbox process launching. See https://crbug.com/40287847. The Notify measurement time starts on the UI thread when the process launch is requested and ends when the UI thread is notified of a successful launch. The PreLaunchDelay variant captures the subset of time spent waiting for the launcher thread to be ready. pasko@chromium.org yfriedman@chromium.org The time it takes to spawn the first child subprocess (including sandbox init). pasko@chromium.org yfriedman@chromium.org The time it takes to spawn child sub processes not counting the first one. simmonsjosh@google.com src/chrome/browser/ash/smb_client/OWNERS The method used to authenticate to a share. This is called on each attempted mount. simmonsjosh@google.com src/chrome/browser/ash/smb_client/OWNERS The result of the GetShares operation for Native SMB File Share. This is recorded after the D-Bus call to GetShares returns. simmonsjosh@google.com src/chrome/browser/ash/smb_client/OWNERS The number of active mounts that a user has. This is recorded after a share has been successfully mounted. simmonsjosh@google.com src/chrome/browser/ash/smb_client/OWNERS The result of the mount operation for Native SMB File Share. This is recorded after the D-Bus call to Mount returns. suzukikeita@chromium.org blink-network-stack@google.com The duration of NetworkQualityEstimator::{MethodName}. This is recorded every time when the method is invoked. hayato@chromium.org blink-network-stack@google.com Counts how many times the result of NetworkQualityEstimator::IsPrivateHost is served from the LRU cache or not. Recorded every time the method is called. hayato@chromium.org blink-network-stack@google.com The duration of NetworkQualityEstimator::IsPrivateHost. Recorded every time the method is called. yyanagisawa@chromium.org chrome-loading@google.com Error between estimation and observation. Absolute value will be recorded for both case estimation is larger than observation and observation is larger than estimation. Recorded when HTTP RTT is going to be updated. yyanagisawa@chromium.org chrome-loading@google.com True if estimation and observation are the same. Recorded when HTTP RTT is going to be updated. yyanagisawa@chromium.org chrome-loading@google.com Error between estimation and observation. Only recorded if observed value is smaller than estimation. Recorded when HTTP RTT is going to be updated. yyanagisawa@chromium.org chrome-loading@google.com Error between estimation and observation. Only recorded if observed value is larger than estimation. Recorded when HTTP RTT is going to be updated. yyanagisawa@chromium.org chrome-loading@google.com True if GetRecentRTT() for {Category} returns invalid RTT under the given threshold but success without the threshold. Recorded when RTT is going to be calculated for updating the effective connection type. yyanagisawa@chromium.org chrome-loading@google.com NQE's estimated RTT comes from weighted medium value in an ObservationBuffer. This is a metrics for {Category}. This metrics tells the duration on how long an observation is kept in the ObservationBuffer so that we can understand how fast the new status will be reflected. Recorded when an observation is added to the buffer and an old observation gets evicted. (Max 1 hour, 100 buckets) yyanagisawa@chromium.org chrome-loading@google.com Number of RTT observations indexed by the source of the observation. Recorded by the network quality estimator every time a new observation is made or synthesized. Warning: this histogram was expired from 2022-02-20 to 2024-07-04; data may missing. yyanagisawa@chromium.org chrome-loading@google.com Rough estimate of the round trip time at the URLRequest layer. Recorded by the network quality estimator every time the effective connection type is computed. Warning: this histogram was expired from 2022-01-16 to 2024-07-04; data may missing. yyanagisawa@chromium.org chrome-loading@google.com Rough estimate of the round trip time at the Transport layer. Recorded by the network quality estimator every time the effective connection type is computed. emaamari@google.com sinhak@chromium.org Outcome of Chrome OS GAIA cookie session restore process. emaamari@google.com sinhak@chromium.org How long it takes for the session restore to fail. emaamari@google.com sinhak@chromium.org How long it takes for the session restore to finish successfully. pbirk@chromium.org src/components/origin_trials/OWNERS Reports whether the presence of a Critical-Origin-Trial header caused a network request restart due to the origin trial not being enabled. The Critical-Origin-Trial header is only processed for navigation requests (loading either a main- or sub-frame) using a safe HTTP verb (per section 4.2.1 of RFC 7231). On those requests, this metric will be emitted if the Critical-Origin-Trial header is present on the response, to report the decision made by the CriticalOriginTrialThrottle. The request may still be restarted due to other throttles, even if this metric reported "false". pbirk@chromium.org src/components/origin_trials/OWNERS Reports status of LevelDB initialization for persistent origin trials. This is emitted on the Init callback during browser startup, and should not be false. A high rate of "false" would indicate a problem with the shared LevelDB database. pbirk@chromium.org src/components/origin_trials/OWNERS Counts the number of origins in the LevelDb database at time of load during browser startup. This metric is for reporting only, and expected to get worse if you are in the process of launching a persistent origin trial. pbirk@chromium.org src/components/origin_trials/OWNERS Reports status of LevelDB load for persistent origin trials. This is emitted on the Load callback during browser startup, and should not be false. A high rate of "false" would indicate a problem with the shared LevelDB database. pbirk@chromium.org src/components/origin_trials/OWNERS Measures the time to load the data from LevelDb during startup in wall clock time. This metric is for reporting only, and expected to get worse if you are in the process of launching a persistent origin trial. pbirk@chromium.org src/components/origin_trials/OWNERS Counts the number of lookups for origins arriving to the LevelDbPersistenceProvider before the database was loaded from disk. Any such lookup would not have seen the persisted value. Since the database is loaded asynchronously, it is possible for the browser to start using the PersistentOriginTrial component before it is fully loaded. Due to this, it is expected to see this metric at 1, possibly 2. Large numbers can be caused by a browser restart with a lot of saved tabs being loaded at the same time. pbirk@chromium.org src/components/origin_trials/OWNERS Counts the number of origins added to the LevelDbPersistenceProvider before the persited origins have loaded from disk. This number represents the number of page loads for pages enrolled in persistent origin trials where the trial was either not activated or the request had to restart due to the presence of the Persistent-Origin-Trial header. pbirk@chromium.org src/components/origin_trials/OWNERS Reports the number of partitions a persistent origin trial token has been stored against. The purpose of the metric is to uncover memory footprint issues from storing site partitions, and to help decide if an eviction strategy needs to be put in place. This metric is recorded once for every stored origin trial token on browser startup. pbirk@chromium.org src/components/origin_trials/OWNERS Records whether a stored partition token has its own origins eTLD+1 as one of the partitions. This is being recorded to determine if space can be saved by making the first-party partition a special case. This metric is recorded on browser startup when the persisted tokens are loaded from the database. mark@chromium.org Usage statistics for the confirm to quit feature. mark@chromium.org MacOS X NSExceptions seen, common exceptions binned, others in overflow. hitawala@chromium.org chrome-gpu-metric-alerts@chromium.org The number of successfully created and cached Gbm Device contexts in GbmSurfaceFactory. Recorded once during the first format texturing support check (lazy initialization). napper@chromium.org robsc@chromium.org When a stylus is touched to screen, the number of palms on the device at that time. robsc@chromium.org The count of the number of held events cancelled when we decide to finally cancel a stroke. Only reported if events have been held, and will be positive. Events are only held from PalmDetectionFilter. robsc@chromium.org The count of the number of held events released at once for a stroke when we decide to release. Only reported if events have been held, and will be positive. Events are only held from PalmDetectionFilter. jiwan@chromium.org robsc@chromium.org The count of the number of detected palm touches. Reported when a new palm touch is detected by either the firmware or the software palm detection. Consecutive palm touch events will be considered as the same palm touch. jiwan@chromium.org robsc@chromium.org Whether a repeated touch is detected soon after palm rejection. Reported when users repeated a touch action within 2 seconds after we rejected the first action as palm. This only emits true when we detect a repeated touch but never emits false. jiwan@chromium.org robsc@chromium.org The count of the number of stylus sessions. A stylus session is a series of stylus events with no more than 5 seconds between them. Reported when a stylus session is concluded. jiwan@chromium.org robsc@chromium.org The length of stylus sessions. A stylus session is a series of stylus events with no more than 5 seconds between them. Reported when a stylus session is concluded. jiwan@chromium.org robsc@chromium.org The time between a stylus touch and the first finger touch after it. The finger touch may or may not be detected as a palm. If the first touch after a stylus touch is another stylus touch (i.e. no finger touch between them), record a maximum time (10 seconds) instead. Reported when first new touch is reported after a stylus touch finishes. jiwan@chromium.org robsc@chromium.org The time between a stylus touch and the last finger touch before it. The finger touch may or may not still be on the touchscreen, and may or may not be detected as a palm. Reported when a stylus touch is started on the touchscreen. jiwan@chromium.org robsc@chromium.org The count of the number of touch sessions. A touch session is a series of touch events with no more than 5 seconds between them. Reported when a touch session is concluded. jiwan@chromium.org robsc@chromium.org The length of touch sessions. A touch session is a series of touch events with no more than 5 seconds between them. Reported when a touch session is concluded. jiwan@chromium.org robsc@chromium.org The type of the first finger touch within 500ms before a stylus touch. It could be finger, palm or none (no touch within 500ms). Reported when a stylus touch is started on the touchscreen. jiwan@chromium.org robsc@chromium.org The type of the last finger touch within 500ms before a stylus touch. It could be finger, palm or none (no touch within 500ms). Reported when first new touch is reported after a stylus touch finishes. hanxi@google.com huangs@google.com wylieb@google.com Records the fetching result of a salient image. The histogram is logged when an salient image is fetched for the {ClientId}. Android-only. sophiechang@chromium.org chrome-journeys@google.com 1456757 Records the result of requests to the Optimization Guide Salient Images backend. Recorded for each request to Optimization Guide, so the total count of this UMA should match that bucket count in PageImageService.Backend. wylieb@google.com chrome-journeys@google.com 1457319 Records the result of requests to the Suggest backend. Recorded for each request to Suggest, so the total count of this UMA should match that bucket count in PageImageService.Backend. wylieb@google.com chrome-journeys@google.com 1457319 Records the backend chosen for the request. For requests with no valid backend, this is still recorded as the "No Valid Backend" bucket. Only recorded for requests that have passed the URL consent gate. wylieb@google.com chrome-journeys@google.com 1457319 Records the result of the URL consent check after timeout has expired. Recorded for each request which was enqueued by the time when timeout happened. wylieb@google.com chrome-journeys@google.com 1457319 Recorded on each URL consent check request. This metric is used to compare numbers with consent check result in PageImageService.ConsentStatus. wylieb@google.com chrome-journeys@google.com 1457319 Records the result of the URL consent check for this request. The number of consent check requests is recorded in PageImageService.ConsentStatusRequestCount. Note that only success and failure are captured if the "old" unified consent throttle is used. nator@chromium.org rayankans@chromium.org Records the number of `periodicsync` events which were fired in a batch. A batch is defined as the set of `periodicsync` events dispatched at the same time by the BackgroundSyncManager. Periodic syncs usually run in a batch. nator@chromium.org rayankans@chromium.org Records whether the fired `periodicsync` events upon completion orginated from a background wakeup task or the foreground. nator@chromium.org rayankans@chromium.org Time taken to execute a batch of periodicsync events. A batch is defined as the set of `periodicsync` events dispatched at the same time by the BackgroundSyncManager. Periodic syncs often run in a batch. michaeldo@chromium.org bling-fundamentals@google.com Page load time for Browser-initiated navigations. Browser-initiated navigations include all navigations initiated by interacting with Chrome's UI elements, except for back/forward navigations. Specifically, typing a URL into the omnibox, tapping the reload button, loading a bookmark, and loading a page from the reading list (including when offline) are all considered browser-initiated. Additionally, background loads for prerendering and reading-list offline sync are also browser-initiated, as is a reload triggered by switching to a tab whose WKWebView renderer process was killed by the OS. This is recorded for successful main-frame navigations (that is, navigations that don't result in the browser displaying an error page). The recorded value measures the time from the navigation request being sent to the renderer process until all frames have fired their load events. For background loads, the same interval is measured while the page loads and fires load events in the background; the metric is not recorded again if the background-loaed page is later displayed in the foreground. Page loads that require network fetches will be slower than those where all necessary resources are already present in WebKit's HTTP cache. Reload navigations where all cached resources are up-to-date are particularly fast, since they don't require any rendering updates either. It is possible for a user to interact with a page before all load events have been fired, so the recorded value should not be interpreted as the time before the page becomes interactive. Most things that affect user-perceived page load time on iOS are within WebKit, not within Chromium/Chrome code. To assess whether a change in this metric is caused by a WebKit change, split by OS version. WebKit changes always come with an OS version change. Obviously, aside from WebKit and Chromium changes, this metric can move due to exogenous factors such as changes in what type of web page people are looking at or changes in the implementation of popular websites. Any navigation that is not considered browser-initiated is considered to be renderer-initiated (see PLT.iOS.RendererInitiatedPageLoadTime2). michaeldo@chromium.org bling-fundamentals@google.com Page load time for Renderer-initiated navigations. Renderer-initiated navigations are all main-frame navigations that are not considered to be browser-initiated (see PLT.iOS.BrowserInitiatedPageLoadTime). Specificially, tapping on links within web content, navigations triggered by JavaScript, navigations for restoring tabs on launch, and back/forward navigations are all considered to be renderer-initiated. This is recorded for successful main-frame navigations (that is, navigations that don't result in the browser displaying an error page). However, this is not recorded when WebKit handles a back/forward navigation using its page cache (that is, when the DOM representation of the destination is still loaded in memory from a recent visit), since we don't get the full set of WebKit navigation callbacks for such navigations. The recorded value measures the time from the browser process being notified that the navigation has started, to all frames having fired their load events. The time that the browser process is notified that the navigation has started is usually just after a network request is sent, but can be later for back/forward navigations on sites that use pushState to generate history entries; in the latter case, the navigation may be almost finished by the time the browser finds out about it. As such, depending on the cause of the navigation, different things are measured. Some types will be very fast (e.g., pushState/replaceState) and others (such as tapping on links) will be slower. Furthermore, navigations that require network fetches will be slower than those where all necessary resources are already present in WebKit's HTTP cache. It is possible for a user to interact with a page before all load events have been fired, so the recorded value should not be interpreted as the time before the page becomes interactive. Most things that affect user-perceived page load time on iOS are within WebKit, not within Chromium/Chrome code. To assess whether a change in this metric is caused by a WebKit change, split by OS version. WebKit changes always come with an OS version change. Obviously, aside from WebKit and Chromium changes, this metric can move due to exogenous factors such as changes in what type of web page people are looking at or changes in the implementation of popular websites. ksakamoto@chromium.org webpackage-dev@chromium.org The number of prefetched signed exchanges in PrefetchedSignedExchangeCache which is attached to a frame. This metric is recorded when the frame is deleted or is navigated to different document. This is not recorded when there is no prefetched signed exchanges. ajgo@chromium.org wfh@chromium.org HashMetricName of dll in kTroublesomeDlls. Recorded if the dll was seen in the browser process and added for blocking in a child process. ajgo@chromium.org wfh@chromium.org True if dwrite hooks were placed during sandbox warmup, false if hooking failed. Emitted once during startup in every sandboxed renderer process where EnableCsrssLockdown is enabled. ajgo@chromium.org wfh@chromium.org Error returned when CreateThreadAction fails to CreateRemoteThread(). Not logged on success. For decoding error code please refer to http://goo.gl/fJJiAv. ajgo@chromium.org wfh@chromium.org Error returned when CreateThreadAction fails to DuplicateHandle(). Not logged on success. For decoding error code please refer to http://goo.gl/fJJiAv. forshaw@chromium.org wfh@chromium.org Errors returned while launching sandboxed process on Windows. For decoding error code please refer to http://goo.gl/fJJiAv. wfh@chromium.org forshaw@chromium.org Errors returned while launching lowbox enabled sandboxed process on Windows. For decoding error code please refer to http://goo.gl/fJJiAv. Warning: this histogram expired in M87, and was revived in M103; data may be missing. ajgo@chromium.org src/sandbox/policy/win/OWNERS Duration of {Event} within StartSandboxedProcess() including the time Windows spends starting the suspended process. Emitted on a successful launch of a sandboxed process on Windows. Only emitted where a high-resolution timer is available (see Windows.HasHighResolutionTimeTicks). kmg@google.com koilos@google.com Records the number of thread type change requests batched together in a single ThreadTypeSwitcher::SetThreadTypes IPC message. Emitted by the browser process when receiving thread priority change requests from a child process on Linux and ChromeOS. peter@chromium.org knollr@chromium.org When a Service Worker receives a push message, this records whether the overall operation was successful, or otherwise the type of error encountered. peter@chromium.org knollr@chromium.org When a webpage asks for details about its current push messaging registration, this records whether the request is successful, or otherwise the type of error encountered. This histogram was expired between 2022-06-26 and 2023-08-04. peter@chromium.org antoniosartori@chromium.org When processing a content setting change for notifications, this counts the number of unsubscribed entries which are currently stored (and need to be iterated upon). peter@chromium.org antoniosartori@chromium.org When processing a content setting change for notifications, this reports how many times (i.e. for how many service workers) the pushsubscriptionchange event is fired. peter@chromium.org knollr@chromium.org When a webpage registers for push messaging, this records whether the request is successful, or otherwise the type of error encountered. This histogram was expired between 2022-06-26 and 2023-08-04. tommasin@chromium.org kartoffel-core-eng@google.com When a new silent push message is received, this records wether a generic notification is shown or not. Additionally it records if the "No silent pushes" enforcement is skipped. peter@chromium.org knollr@chromium.org When unregistering a website from push messaging, this records the reason why it is being unregistered. peter@chromium.org knollr@chromium.org When unregistering a website from push messaging, this records whether the request is successful, or otherwise the type of error encountered. This histogram was expired between 2022-06-26 and 2023-08-04. mastiz@chromium.org mmrashad@google.com treib@chromium.org When an entry is added or replaced in the reading list, records in which storage this happened. gambard@chromium.org bling-team@google.com Number of tries before the download of the entry is successful. gambard@chromium.org bling-team@google.com Final status of the download of a reading list entry. gambard@chromium.org bling-team@google.com Time since the first read of the reading list entry getting deleted. 0 if it has never been read. gambard@chromium.org bling-team@google.com Whether the displayed version is the offline one. gambard@chromium.org bling-team@google.com Time since the creation of the read reading list entry getting deleted. gambard@chromium.org bling-team@google.com Number of read entries in reading list. gambard@chromium.org bling-team@google.com Time since the creation of the unread reading list entry getting deleted. gambard@chromium.org bling-team@google.com Number of unread entries in reading list. corising@chromium.org top-chrome-desktop-ui@google.com The amount of time between the RenderFrameHost StartProvisionalLoad event and the RenderFrameHost DocumentOnLoadCompleted event for the Read Later WebUI page. corising@chromium.org top-chrome-desktop-ui@google.com The amount of time between the RenderFrameHost StartProvisionalLoad and DidFinishDocumentLoad events for the Read Later WebUI page. mastiz@chromium.org mmrashad@google.com treib@chromium.org top-chrome-desktop-ui@google.com The number of {ReadStatus} items in the reading list {StorageState}. Recorded {RecordedAt}. victortan@chromium.org awillia@chromium.org miketaylr@chromium.org Count of requests restarted or the reason why not restarted when reducing accept-language HTTP header. victortan@chromium.org awillia@chromium.org miketaylr@chromium.org Measure how often user accept-language is empty when reading accept-language from prefs. victortan@chromium.org awillia@chromium.org miketaylr@chromium.org The latency (in milliseconds) to clear the reduce accept language for a given origin in the language negotiation cache. This histogram is recorded when clearing persisted value from PrefService. victortan@chromium.org awillia@chromium.org miketaylr@chromium.org The latency (in microseconds) to fetch the reduce accept language for a given origin in the language negotiation cache. This histogram is recorded when fetching persisted value from PrefService. Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution. When considering revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the solution. victortan@chromium.org awillia@chromium.org miketaylr@chromium.org The latency (in milliseconds) to store the reduced accept language header value for a given origin in the language negotiation cache. This histogram is recorded when navigation responses are being processed. victortan@chromium.org awillia@chromium.org miketaylr@chromium.org Count of reduce accept language that need to be persisted to the disk. Recorded by the renderer. This histogram is recorded when navigation responses are being processed. wfh@chromium.org src/net/reporting/OWNERS The exact database error encountered when initializing the Reporting and NEL database, if initialization fails catastrophically. This is recorded if the database initialization fails catastrophically when the DB initialization attempt is made, which typically occurs upon the first network request after startup. Catastrophic errors are defined in sql::IsErrorCatastrophic. yhirano@chromium.org src/net/reporting/OWNERS The number of NEL policies loaded from the store. This is recorded when the NetworkErrorLoggingService requests a load from the backing store, which typically happens upon the first network request after startup. yhirano@chromium.org src/net/reporting/OWNERS The number of NEL policies loaded from the store. This is recorded when the NetworkErrorLoggingService requests a load from the backing store, which typically happens upon the first network request after startup. yhirano@chromium.org src/net/reporting/OWNERS The number of Reporting endpoint groups loaded from the store. This is recorded when the ReportingCache requests a load from the backing store, which happens upon receipt of the first Report-To header or queued report after startup. yhirano@chromium.org src/net/reporting/OWNERS The number of Reporting endpoints loaded from the store. This is recorded when the ReportingCache requests a load from the backing store, which happens upon receipt of the first Report-To header or queued report after startup. yhirano@chromium.org src/net/reporting/OWNERS The time (ms) taken to initialize the Reporting and NEL DB. This is recorded when the DB is initialized, which typically occurs upon the first network request after startup. iclelland@chromium.org issackjohn@microsoft.com src/net/reporting/OWNERS Tracks the outcome of crash reports for unresponsive renderers. Including when error dialogs are suppressed (e.g., running with --noerrdialogs), specifically categorizing the reports as either potentially queued for sending or dropped. This metric helps evaluate the potential impact of automatically sending crash reports in the scenario where the error dialogs are suppressed, aiming to improve crash report send rates without overwhelming the system with duplicates. Recorded once for each visible WebContents when it is observed to be unresponsive. wfh@chromium.org src/net/reporting/OWNERS The result of calling ::GetLastError() if initializing the Reporting and NEL database fails catastrophically. This is recorded, on Windows only, if the database initialization fails when the DB initialization attempt is made, which typically occurs upon the first network request after startup. Catastrophic errors are defined in sql::IsErrorCatastrophic. behnoodm@chromium.org cryptohome-core@google.com This metric is recording users' usage of the Sanitize SWA. Different histograms show the interaction of the user with the SWA. This UMA records when the initial page is opened, when the safety reset starts, and when the done page is shown after the reset is completed. xinghuilu@chromium.org chrome-counter-abuse-alerts@google.com Records results of SafeBrowsing download url check. Warning: this histogram was expired from M78 to M91. Data may be missing. This metric is used to populate a dashboard on go/crsb-site. xinghuilu@chromium.org chrome-counter-abuse-alerts@google.com The time it takes for SafeBrowsing to check a download url. Warning: this histogram was expired from M78 to M91. Data may be missing. vakh@chromium.org chrome-counter-abuse-alerts@google.com Count of how many URLs were actually checked vs skipped via RemoteSafeBrowsingDatabaseManager because the scheme is not supported by Safe Browsing. Incremented each time a resource load is initiated. xinghuilu@chromium.org chrome-counter-abuse-alerts@google.com Count of how many URLs were actually checked by {CheckType} vs skipped via RemoteSafeBrowsingDatabaseManager because the scheme is not supported by Safe Browsing. Incremented each time a resource load is initiated. Different check types are not directly comparable because hash real time checks have applied pre-filtering before this histogram is logged while hash database checks haven't. vakh@chromium.org chrome-counter-abuse-alerts@google.com Latency of URL-classification API calls from Chrome via RemoteSafeBrowsingDatabaseManager, logged per-request. This includes the time to go through JNI, check the URL, and return the result and includes several thread hops betwetween IO and UI threads. The resource-load will not necessarily be delayed this much (see SB2.Delay for that). vakh@chromium.org chrome-counter-abuse-alerts@google.com The type of incident discarded by the safe browsing incident reporting service as a result of profile or service destruction. vakh@chromium.org chrome-counter-abuse-alerts@google.com The type of incident given to the safe browsing incident reporting service but dropped as a result of not participating in safe browsing. vakh@chromium.org chrome-counter-abuse-alerts@google.com The type of incident included in an incident report by the safe browsing incident reporting service. vakh@chromium.org chrome-counter-abuse-alerts@google.com The type of incident pruned by the safe browsing incident reporting service as a result of not having a matching binary download. vakh@chromium.org chrome-counter-abuse-alerts@google.com The type of incident pruned from a report in the safe browsing incident reporting service as a result of having previously been reported. vakh@chromium.org chrome-counter-abuse-alerts@google.com The type of incident received by the safe browsing incident reporting service. vakh@chromium.org chrome-counter-abuse-alerts@google.com The size, in bytes, of a safe browsing incident report. caitkp@google.com The result of an attempted report upload by the safe browsing incident reporting service. antrim@chromium.org cros-oac@google.com What type of authentication was attempted when the user failed to unlock the lock screen. antrim@chromium.org cros-oac@google.com The time spent for authentication in case of a failure. antrim@chromium.org cros-oac@google.com What type of authentication was attempted when the user successfully unlocked the lock screen. antrim@chromium.org cros-oac@google.com The time spent for authentication in case of a success. antrim@chromium.org cros-oac@google.com The time spent before the screen locker is ready. charleszhao@chromium.org chromeos-platform-power@google.com The duration for the screen to be in locked/unlocked state. Recorded inside ScreenlockMonitor, when the screen lock state changes. hanxi@chromium.org yfriedman@chromium.org hnakashima@chromium.org mheikal@chromium.org Histogram of how Chrome is launched, either in ServiceManager only mode or as full browser, as well as either cold start or warm start. See go/servicification_startup_metrics for more details. hanxi@chromium.org yfriedman@chromium.org hnakashima@chromium.org mheikal@chromium.org Histogram of how Chrome is launched, either in ServiceManager only mode or as full browser, as well as either cold start or warm start. See go/servicification_startup_metrics for more details. The UMA data is cached in the SharedPreference compared with Servicification.Startup2, which might lose some data when Chrome is running in the ServiceManager only mode. etienneb@chromium.org gab@chromium.org Time duration for shutdown initiated by the browser exit menu command. The duration covers from the shutdown trigger to the deletion of the BrowserImpl. Note: Android does not have shutdown metrics. etienneb@chromium.org gab@chromium.org Time duration for shutdown initiated by an end session (user logs off, shuts down or reboots without explicitly exiting).The duration covers from the shutdown trigger to the deletion of the BrowserImpl. Note: Android does not have shutdown metrics. etienneb@chromium.org gab@chromium.org Time for shutdown for a not valid exit. This situation happen when a chrome process is already running and the process is terminated after the process singleton rendez-vous. The duration covers from the shutdown trigger to the deletion of the BrowserImpl. Note: Android does not have shutdown metrics. etienneb@chromium.org gab@chromium.org Time duration for clean shutdown that are not catched by other not initiated by the users. The duration covers from the shutdown trigger to the deletion of the BrowserImpl. Note: Android does not have shutdown metrics. etienneb@chromium.org gab@chromium.org The action type that triggered a browser shutdown. The metric is emitted just after BrowserImpl deletion. Note: Android does not have shutdown metrics. In M-108, the detection of shutdown due to early exit paths changed and these shutdowns will be moved from the NotValid bucket to the Other bucket. etienneb@chromium.org gab@chromium.org Time for shutdown for a silent exit. The duration covers from the shutdown trigger to the deletion of the BrowserImpl. Note: Android does not have shutdown metrics. aattar@google.com catan-team@chromium.org The total wall-clock time spent in the page unload process during a user-initiated browser shutdown, for cases where the shutdown was canceled by the user. This is measured from the start of the exit attempt until the user cancels the action, typically via a beforeunload dialog. aattar@google.com catan-team@chromium.org The total wall-clock time spent processing beforeunload and unload handlers during a user-initiated browser shutdown, for cases where the shutdown was confirmed. This is measured from the start of the exit attempt until all unload-related handlers have completed. aattar@google.com catan-team@chromium.org Measures the time from when a renderer process shutdown is initiated via RenderProcessHost::Shutdown() until the process has actually terminated. High values can indicate a hung or busy renderer. Recorded per process. etienneb@chromium.org gab@chromium.org Time for shutdown initiated by the last browser window being closed. The duration covers from the shutdown trigger to the deletion of the BrowserImpl. Note: Android does not have shutdown metrics. ksakamoto@chromium.org webpackage-dev@chromium.org Records if the fetched Signed Exchange certchain was served from HTTP cache or not. ksakamoto@chromium.org webpackage-dev@chromium.org Reports the result of Signed Exchange CT verification, including success. ksakamoto@chromium.org webpackage-dev@chromium.org Records true when a fallback redirect of Signed Exchange has failed with ERR_TO_MANY_REDIRECTS. Total count of SignedExchange.LoadResult2 should be used as a baseline of this histogram. ksakamoto@chromium.org webpackage-dev@chromium.org Records the result of loading a resource from Signed HTTP Exchange. Emitted each time a response is handled as Signed Exchange. ksakamoto@chromium.org webpackage-dev@chromium.org The status of OCSP response in Signed Exchange certificates. Reported each time Signed Exchange's OCSP check is performed. ksakamoto@chromium.org webpackage-dev@chromium.org Reports the revocation status of OCSP response in Signed Exchange certificates. Emitted when Signed Exchange's OCSP check is performed, but only when an up-to-date OCSP response was stapled. ksakamoto@chromium.org webpackage-dev@chromium.org Records if the prefetched Signed Exchange was properly formatted and passed verification steps. Reported for each completed SignedExchange prefetch. ksakamoto@chromium.org webpackage-dev@chromium.org Recorded when Signed Exchange signature was expired. Records the time delta between current time and signature's "expires" value. ksakamoto@chromium.org webpackage-dev@chromium.org Recorded when Signed Exchange signature was not yet valid. Records the time delta between current time and signature's "date" value. ksakamoto@chromium.org webpackage-dev@chromium.org Reports the result of Signed Exchange signature verification, including success. ksakamoto@chromium.org webpackage-dev@chromium.org The amount of time elapsed to fetch certificate chain from certUrl, for which the fetch has failed. ksakamoto@chromium.org webpackage-dev@chromium.org The amount of time elapsed to fetch certificate chain from certUrl, for which the fetch has succeeded. ksakamoto@chromium.org webpackage-dev@chromium.org The amount of time that elapsed during SignedExchangeSignatureVerifier::Verify. ksakamoto@chromium.org webpackage-dev@chromium.org Number of seconds until the Signed Exchange's expiration time. Recorded when Signed Exchange signature verification is performed, and emitted only for Signed Exchanges within the validity period. olivierli@chromium.org leszeks@chromium.org catan-team@chromium.org The size in bytes of data being stored in the code cache. Recorded on receiving the cached code. Recorded only if the size in non-zero. awillia@chromium.org loading-dev@chromium.org The behaviour of site isolated javascript code cache recorded for each cache transaction. It records if the request was serviced and if serviced how it was serviced for ex: hit, miss, update. Warning: this histogram was expired from 2022-07-24 to 2023-04-03; data may be missing. yhirano@chromium.org loading-dev@chromium.org The amount of time spent to fetch a code cache. Recorded only for a JS code cache, and recorded only when a non-empty code cache is found. yhirano@chromium.org loading-dev@chromium.org Represents whether fetching from the code cache succeeded. Recorded when the code cache result gets available. yhirano@chromium.org loading-dev@chromium.org The amount of time that could be saved if we had a memory-backed code cache. Recorded when the code cache result gets available. tluk@chromium.org The behaviour of site isolated WebUI JS code cache recorded for each cache transaction. It records if the request was serviced and if serviced how it was serviced for ex: hit, miss, update. tluk@chromium.org chrome-webui-for-features@google.com The behaviour of site isolated WebUI JS code cache recorded for each cache transaction for the WebUI origin {WebUIHostnameForCodeCache}. It records if the request was serviced and if serviced how it was serviced (eg hit, miss, update). tluk@chromium.org chrome-webui-for-features@google.com The behaviour of site isolated WebUI JS code cache recorded for each cache transaction for a resource under the WebUI host {WebUIHostnameForCodeCache}. It records if the request was serviced and if serviced how it was serviced (eg hit, miss, update). awillia@chromium.org loading-dev@chromium.org The behaviour of site isolated web assembly code cache recorded for each cache transaction during WASM compilation. It records if the request was serviced and if serviced how it was serviced for ex: hit, miss, update. Warning: this histogram was expired from 2020-04-19 to 2023-04-03; data may be missing. hdchuong@google.com essential-inputs-team@google.com Logged whenever a {UnderlineType} error underline is generated by the Android OS spell checker. hdchuong@google.com essential-inputs-team@google.com Logged whenever a text check request is dispatched via SpellCheckerSessionBridge to the Android OS spell checker on Android. hdchuong@google.com essential-inputs-team@google.com Length (in character code units) of a {UnderlineType} error underline returned by the Android OS spell checker. shend@chromium.org essential-inputs-team@google.com The length of text checked via async checking. Warning: this histogram was expired from M83 to M107; data may be missing. shend@chromium.org essential-inputs-team@google.com The length of text checked by spellCheck. No replacement suggestions were requested. Warning: this histogram was expired from M83 to M107; data may be missing. shend@chromium.org essential-inputs-team@google.com The length of text checked by spellCheck. Replacement suggestions were requested. Warning: this histogram was expired from M83 to M107; data may be missing. groby@chromium.org The number of times the platform spelling UI was enabled/disabled. sisidovski@chromium.org chrome-loading@google.com Logs the time taken to run SpellcheckService::InitForRenderer. This is recorded whenever a new renderer process is created. shend@chromium.org essential-inputs-team@google.com The number of words checked within a session. Warning: this histogram was expired from M83 to M107 and also from 2024-12 to 2026-08; data may be missing. shend@chromium.org essential-inputs-team@google.com The average number of words checked per hour. Sampled every 30 minutes. Warning: this histogram was expired from M83 to M107; data may be missing. shend@chromium.org zsun@igalia.com Number of words accepted into a single RenderFrame's per-document custom dictionary, which is populated via the SpellCheckCustomDictionary web API. Recorded once per document, when the document is replaced by a new document (navigation) or the frame is torn down. Documents that never added a word through the API are not recorded. shend@chromium.org essential-inputs-team@google.com The number of sessions that started with spellchecking enabled. Recorded only for regular profiles. (Not recorded on guest profiles for example.) shend@chromium.org essential-inputs-team@google.com The number of misspelled words within a session. Warning: this histogram was expired from M83 to M107 and also from 2024-12 to 2026-08; data may be missing. sisidovski@chromium.org chrome-loading@google.com Logs the time taken to run SpellCheck::Initialize on the renderer main thread. This encompasses the construction of the custom dictionary and takes place during renderer initialization. shend@chromium.org essential-inputs-team@google.com The number of misspelled-but-replaced words within a session. Warning: this histogram was expired from M83 to M107 and also from 2024-12 to 2026-08; data may be missing. shend@chromium.org essential-inputs-team@google.com The number of occurrences that shows spelling suggestion within a session. This is incremented and logged when a context menu with spelling suggestions is shown for a misspelled word. Warning: this histogram was expired from M83 to M107 and also from 2024-12 to 2026-08; data may be missing. shend@chromium.org essential-inputs-team@google.com Whether the user has opted in to asking Google for spelling suggestions. Recorded only for regular profiles. (Not recorded on guest profiles for example.) Recorded both when spelling is initialized and when the preference is changed. shend@chromium.org essential-inputs-team@google.com The HTTP code of Spelling service responses. shend@chromium.org essential-inputs-team@google.com Describes the results returned by the Spelling service by assigning them to one of three high-level buckets: request/service error, success with no suggestions, and success with spelling suggestions. shend@chromium.org essential-inputs-team@google.com The percentage of replacement executions within suggestion occurrences. Warning: this histogram was expired from 2024-12 to 2026-08; data may be missing. shend@chromium.org essential-inputs-team@google.com Counts how many languages are added to Chrome by the user but are not supported for spell check (today Chrome only supports a hard-coded list of locales for spell check). Recorded only for regular profiles. (Not recorded on guest profiles for example.) This is a measure of the potential impact of adding support for non-Hunspell locales in the spell check settings. This also helps answer the following question: should the Chrome spell check settings raise awareness of Windows language packs and / or link to documentation describing how to install a Windows language pack? This is recorded once during spell check initialization, and then once each time the user changes their Chrome languages. {Spellcheck_Windows_LocaleSupportType} shend@chromium.org essential-inputs-team@google.com Of all the currently enabled spell check languages, counts how many are supported by the different spell checkers (Hunspell and the Windows OS). Recorded only for regular profiles. (Not recorded on guest profiles for example.) This helps measure the impact and reach of the native spell checker integration. This is recorded once during spell check initialization, and then once each time the user changes their enabled spell check languages. {Spellcheck_Windows_LocaleSupportType} shend@chromium.org essential-inputs-team@google.com Measures the time it takes to perform one spell check end to end. The start time is taken just before invoking Hunspell or the native spell checker (via Mojo), and the end time is taken just before invoking the Blink spell check callback. This is recorded every time a spell check is performed. {Spellcheck_Windows_SpellcheckType} shend@chromium.org essential-inputs-team@google.com Measures the time it takes to generate spelling suggestions when a user right clicks a misspelled word. The start time is taken just before invoking Hunspell for the suggestions, and the end time is taken just after the final suggestion list is constructed. This is recorded every time the user opens the context menu on a misspelled word, but only if the suggestions hadn't been pre-generated (which happens when all spell check locales are supported by the OS spell checker). {Spellcheck_Windows_SpellcheckType} jlebel@chromium.org chrome-signin-team@google.com Number of accounts available for Single Sign On with the current device, recorded at the time the SSO Promo is shown. jlebel@chromium.org chrome-signin-team@google.com Action the user takes when the Single Sign On promotion is shown. jlebel@chromium.org chrome-signin-team@google.com Number of times the promotion has been seen on the current device. futhark@chromium.org Microseconds spent in StyleEngine::InvalidateStyle. Only samples from high resolution timers are recorded. futhark@chromium.org Microseconds spent in RebuildLayoutTree called from Document::UpdateStyle. futhark@chromium.org Microseconds spent in RecalcStyle called from Document::UpdateStyle. hayato@chromium.org webpackage-dev@chromium.org The net error code recorded when request for a subresource web bundle was failed. hayato@chromium.org webpackage-dev@chromium.org The value of content length header of a subresource web bundle, or zero if the content-length header is missing. hayato@chromium.org webpackage-dev@chromium.org The result of loading subresource web bundles. hayato@chromium.org webpackage-dev@chromium.org The max memory usage per renderer process for subresource web bundles which are kept in the network process's memory. Recorded when all the subresource web bundles for the renderer process are released. hayato@chromium.org webpackage-dev@chromium.org The counts of Web Bundles origin types requested by Subresource Loading with Web Bundles. Recorded when a script element whose type is webbundle is inserted into a document. hayato@chromium.org webpackage-dev@chromium.org The received data size of a subresource web bundle. Recorded when received all the body of the subresource web bundle. hayato@chromium.org webpackage-dev@chromium.org The number of resources contained in a web bundle. Recorded when bundle metadata is received and parsed successfully. sophiechang@chromium.org chrome-intelligence-core@google.com Records AI subscription tier status for profiles available on this install. Emitted in every UMA record from the current session (at the time the record is finalized). minch@chromium.org omrilio@chromium.org The number of each volume adjust type in tablet mode. Logged when starts volume adjust while in tablet mode. alemate@chromium.org michaelpg@chromium.org Events in TimeZoneRequest. alemate@chromium.org michaelpg@chromium.org Http response codes in TimeZoneRequest. alemate@chromium.org michaelpg@chromium.org The time elapsed between the sending of the first API request and the time the final (failed) response was recorded. Includes all retries. alemate@chromium.org michaelpg@chromium.org The time elapsed between the sending of the first API request and the time the final (successfull) response was recorded. Includes all retries. alemate@chromium.org michaelpg@chromium.org Result of TimeZoneRequest. alemate@chromium.org michaelpg@chromium.org Number of retries until the final response was recorded. girard@chromium.org input-dev@chromium.org Recorded when a touch event excludes an active touch (a touch-id/dwId that previously generated a TOUCHEVENTF_DOWN, and has not since generated a TOUCHEVENTF_UP). Chromium generates a simulated event to maintain consistency/correctness. Only recorded on Windows. Warning: This histogram was expired after M95, and resurrected in M108. This workaround will be removed once usage drops off. See https://crbug.com/811273 for details. ssid@chromium.org Reason why background tracing finalization was not allowed. Also see "Tracing.Background.ScenarioState" metric, which records the total number of times finalization was allowed and not allowed. etiennep@chromium.org chrometto-team@google.com Records Perfetto Tracing Trigger name hash when they occur. Tracing Triggers defined in a proto scenario config from third_party/perfetto/protos/perfetto/config/chrome/scenario_config.proto and are usually based on named events or histograms. etiennep@chromium.org chrometto-team@google.com Records the elapsed time from TracingSession::ReadTrace initial call until all data is received in the browser process. etiennep@chromium.org chrometto-team@google.com Records Background Tracing {Type} Trigger name hash when they occur. Tracing Triggers defined in a proto scenario config from third_party/perfetto/protos/perfetto/config/chrome/scenario_config.proto and are usually based on named events or histograms. etiennep@chromium.org chrometto-team@google.com Records Background Tracing scenario name hash when event {Event} occurs. oysteine@chromium.org Records state of the Background Tracing system, from when scenarios are attempted to be activated until they're completed (successfully or failed) etiennep@chromium.org grt@chromium.org The HRESULT from the {Stage} stage while launching the elevated tracing service on Windows. A value is recorded for each stage while processing a launch of the service until either a failure is reached, or the final stage succeeds. Typically, the service is started at most once per browser process. pbirk@chromium.org webview-team@google.com chrometto-team@google.com Records the total time spent by tracing::InitTracing. This histogram is added to investigate the impact of Tracing initialization on WebView startup performance. pbirk@chromium.org webview-team@google.com chrometto-team@google.com Records the time spent by perfetto::Tracing::Initialize during PerfettoTracedProcess::SetupClientLibrary. This histogram is added to investigate the impact of Tracing initialization on WebView startup performance. eseckler@chromium.org tracing@chromium.org Records success or failure of creating the shared buffer in ProducerClient::InitSharedMemoryIfNeeded() msarda@chromium.org droger@chromium.org State of the user settings for making searches and browsing better, recorded each time a regular profile is loaded (this histogram is not recoded for system profiles, guest profiles, off-the-record profiles or irregular ChromeOS profiles). droger@chromium.org msarda@chromium.org All *off* sync data types are recorded when the user confirmed the sync setup after going through the advanced opt-in flow. deckerjames@google.com sorin@chromium.org Records the result of Client Update Protocol (CUP) signature validation of a server response. Recorded once per validation attempt, i.e. each time update_client receives an HTTP-successful response for a request sent with CUP signing enabled (update checks and pings). A failed validation may be retried against a fallback URL, recording an additional sample. Not recorded for requests that fail at the network level. deckerjames@google.com sorin@chromium.org Measures the time taken to validate the Client Update Protocol (CUP) signature of a server response. Recorded on the same occasions as UpdateClient.CupValidationResult, for both successful and failed validations. Granularity is 1 ms, so sub-millisecond validations all record in the minimum bucket. noahrose@google.com sorin@chromium.org Measures the time it takes to complete a download for {AppID}. Counted only for successful downloads. noahrose@google.com sorin@chromium.org Measures the time it takes to unzip a component for {AppID}. Counted only for successful unzips. emshack@chromium.org top-chrome-desktop-ui@google.com Measures the days elapsed from an update being visible to the browser and the browser being restarted or quit. Warning: this histogram expired after M87, and was re-added in M92; data may be missing. emshack@chromium.org top-chrome-desktop-ui@google.com Measures the hours elapsed from an update being visible to the browser and the browser being restarted or quit. mpolzer@google.com crisguerrero@chromium.org chromeos-commercial-remote-management@google.com Tracks what is the reason we're doing a rollback instead of an update (going to a more stable channel or admin-initiated enterprise rollback). We're showing different notifications depending on the reason. Sent when the device finished installing the rollback image, shows the notification and is waiting for reboot. This metric is specific to ChromeOS. hidehiko@chromium.org junis@google.com cros-oac@google.com Measures the time elapsed on Chrome OS between when Chrome is started, and when the login prompt is again visible after a logout. This statistic is only collected when preceeded by a logout. Warning: this histogram was expired from M77 to M96 some data may be missing. satorux@chromium.org hashimoto@chromium.org The system uptime on Chrome OS when the dbus-daemon process crashes, resulting in a reboot. Warning: this histogram was expired from M85 to M118 some data may be missing. hidehiko@chromium.org junis@google.com cros-oac@google.com Measures the time elapsed on Chrome OS for setting up for a login after a logout. More specifically, it is the time between when the Cryptohome is unmounted (the last step in the logout process) and when the login prompt is again visible after a logout. Warning: this histogram was expired from M85 to M96 some data may be missing. hidehiko@chromium.org junis@google.com cros-oac@google.com Measures the time elapsed on Chrome OS when performing a logout. More specifically, it is the time between when a logout is initiated and when the Cryptohome is unmounted, signaling the last step in the logout process. This statistic is not collected when the logout is part of a restart or shutdown. Warning: this histogram was expired from 09/2020 to M96 some data may be missing. hidehiko@chromium.org junis@google.com cros-oac@google.com Measures the time elapsed on Chrome OS between initiating a logout and the next time the login prompt is visible again. This statistic is not collected if the machine is shutdown between the logout initiation and the prompt becoming visible. Warning: this histogram was expired from M77 to M96 some data may be missing. hidehiko@chromium.org junis@google.com cros-oac@google.com Measures the time elapsed on Chrome OS between when a logout is initiated and the UI has stopped (and Chrome has exited) during the logout process. This statistic is not collected if the logout is part of a restart or shutdown. Warning: this histogram was expired from M77 to M96 some data may be missing. hidehiko@chromium.org junis@google.com cros-oac@google.com Measures the time elapsed on Chrome OS between when all user-associated processes have been terminated during the logout process and when Chrome is started again to show the login screen. Warning: this histogram was expired from M77 to M96 some data may be missing. hidehiko@chromium.org junis@google.com cros-oac@google.com Measures the time elapsed on Chrome OS between when the UI has stopped (Chrome has exited), and when all other associated processes have been terminated during the logout process. This statistic is not collected if the logout is part of a restart or shutdown. Warning: this histogram was expired from M77 to M96 some data may be missing. pnoland@chromium.org fgorski@chromium.org Android: count of Usage Stats events. Recorded as these events occur; e.g. when a domain is associated with a token, or a site is suspended. jasontt@chromium.org assistive-eng@google.com Distribution of the device images that users changed (Chrome OS). The statistic is recorded each time the user changes their device image to a different one in Settings. This metric expired in March 2022 and was revived in M105. Data between these times is incomplete. This metric supersedes `UserImage.Changed` due to a change in enum values. achuith@chromium.org jasontt@chromium.org assistive-eng@google.com cros-oac@google.com Distribution of the default images that existing users log in with (Chrome OS). One sample is taken each time the user logs in. This metric supersedes UserImage.LoggedIn2 due to a change in enum values. Special value 0 (Camera image) of ChromeOSUserImageId2 is never recorded in this histogram. Warning: this histogram was expired from 2022-03-30 to 2022-08-01; data may be missing. achuith@chromium.org antrim@chromium.org cros-lurs@google.com The number of users of different types that log in to the system (Chrome OS). alemate@chromium.org antrim@chromium.org cros-lurs@google.com The time between one regular user logging out and a different regular user logging in (Chrome OS). Delays above thirty minutes or which span system reboots or non-regular-user logins are not reported. hidehiko@chromium.org junis@google.com cros-oac@google.com This is logged when new user type reported by Gaia is different from the old one (for existing user). basiaz@google.com chrome-language@google.com Android: The source of a dismissed voice search, such as omnibox or NTP. This is recorded after the dismissed intent returns to Chrome. basiaz@google.com chrome-language@google.com Android: The source of a failed voice search, such as omnibox or NTP. This is recorded after any intent failure, which could occur before an intent is sent (if the send fails) or after the intent returns unsuccessfully. It will only be recorded once. basiaz@google.com chrome-language@google.com Android: The source of a successful voice search, such as omnibox or NTP. This is recorded immediately after the successful intent returns to Chrome. basiaz@google.com chrome-language@google.com Android: The source of a voice search start event, such as omnibox or NTP. This is recorded immediately before the voice transcription intent is sent. basiaz@google.com chrome-language@google.com Android: Records the confidence value of a successful voice search as a percentage. This is recorded when the voice intent returns successfully. Warning: this histogram was expired from 2024-04-28 to 2024-08-19; data may be missing. basiaz@google.com chrome-language@google.com Android: Records whether the voice search produced results. This is recorded when the voice intent returns successfully. cduvall@chromium.org sisidovski@chromium.org chrome-loading@google.com Measures the time it takes to call all observers of the WebContents observer method {Method} in {FrameType}. Logged every time the method is called. WARNING: This method may have been expired from 2023-07-28 to 2024-06-02. gambard@chromium.org bling-fundamentals@google.com [iOS] Report cache hit/miss for WKWebView cert verification. CRWWKNavigationHandler has a cache of pending cert verification results to avoid extra verifications when presenting SSL interstitial. This metric helps to understand how often this cache miss happens. kenjibaheux@chromium.org ksakamoto@chromium.org A histogram tracking the time we spent showing blank text because a web font wasn't available by the time we needed it. Measured once per @font-face that ended up showing blank text. hajimehoshi@chromium.org kenjibaheux@chromium.org kouhei@chromium.org ksakamoto@chromium.org Recorded upon web fonts load. Counts the number of times web font is loaded from cache (disk cache or memory cache), fetched over network, or served from data URL. xiaochengh@chromium.org chrome-rendering-core@google.com Recorded when render-blocking web font preloads have reached the maximum blocking time, and therefore, turned into non-render-blocking. Records the number of web font preloads that are still pending. This is a diagnostic metric for feature RenderBlockingFonts. kenjibaheux@chromium.org ksakamoto@chromium.org The time taken for a webfont download that failed. Includes aborted requests. kenjibaheux@chromium.org ksakamoto@chromium.org This metrics is logged when a page that use web fonts is loaded. The value is whether we had to wait on at least one web font and ended up showing blank text, or not. hajimehoshi@chromium.org kenjibaheux@chromium.org kouhei@chromium.org ksakamoto@chromium.org Whether a locallly installed font is actually used when @font-face had local sources. mgiuca@chromium.org Counts the number of calls to navigator.share. Includes both successful and failed shares. thefrog@chromium.org chrome-counter-abuse-alerts@google.com Records the result of the Safe Browsing download check when sharing a file via the WebShare API. Logged each time a check completes (safe, unsafe, or timeout). mgiuca@chromium.org Records the outcome of calls to navigator.share. This will not count any calls that never complete (e.g., if the page closes while the picker is open). Therefore, DO NOT look at the raw percentages of this histogram; instead, compare these numbers with the WebShare.ApiCount.Share total. NOTE: At the moment, if the user cancels the picker, its recording will be delayed, and possibly never recorded (https://crbug.com/636274), so that will account for a discrepancy between ShareOutcome and ApiCount.Share. reillyg@chromium.org Records the reason why the WebUSB device chooser was closed. alvinji@google.com robpitkin@google.com reillyg@chromium.org Records the interface class code of a protected interface when a {Direction} {Type} control transfer is blocked by DeviceImpl. This helps identify which device classes are being targeted by specific control request types. alvinji@google.com robpitkin@google.com reillyg@chromium.org Records the outcome of the control transfer permission check. This is used to measure the impact of the fix for bypassing protected USB class restrictions. ovn@google.com lt-web-apps-team@google.com Records the outcome of detaching a kernel driver during ClaimInterface (for Android and Linux only). alvinji@chromium.org deviceapi-team@google.com Records why an endpoint operation in DeviceImpl failed the endpoint ready check (IsEndpointReadyForTransfer). reillyg@chromium.org Records the reason why the "WebUSB device detected" notification was dismissed. reillyg@chromium.org Records when the user revokes permission for an origin to connect to a USB device using the WebUSB API. alvinji@chromium.org deviceapi-team@google.com Records the connection context when a WebUSB operation in DeviceImpl is blocked because a device or interface state change is in progress. Differentiates between state changes initiated by the same device connection vs another device connection. alvinji@chromium.org deviceapi-team@google.com Records which WebUSB Mojo method was blocked in DeviceImpl because a device or interface state change was in progress.