MD Settings/Options: add equivalent logs for "time until interactive"

chrome/browser/resources/settings/settings_ui/settings_ui.js

Index: chrome/browser/resources/settings/settings_ui/settings_ui.js
diff --git a/chrome/browser/resources/settings/settings_ui/settings_ui.js b/chrome/browser/resources/settings/settings_ui/settings_ui.js
index 91a143e06f78dd2340faad009165f9e03a40620a..ea70eceb194e7b1c1132a6751677f2a0c0d6a622 100644
--- a/chrome/browser/resources/settings/settings_ui/settings_ui.js
+++ b/chrome/browser/resources/settings/settings_ui/settings_ui.js
@@ -158,6 +158,11 @@ Polymer({
 
   /** @override */
   attached: function() {
+    setTimeout(function() {
+      chrome.send(
+          'metricsHandler:recordTime',
+          ['Settings.TimeUntilInteractive', window.performance.now()]);

[dpapad, 2017/02/25 01:04:08]

How do we differentiate between old VS new timings? Do we care about the case
where
 1) a user with enabled MD Settings goes to chrome://settings-frame?
 2) a user with disabled MD Settings goes to chrome://md-settings?

Would those mess up the metrics by recording both metrics in the same bucket?

[Dan Beam, 2017/03/04 02:36:05]

i really don't care, to be honest.

in the case of ChromeOS, we really should be comparing against settings-frame. 
that's how users get to settings.

on the case of desktop, we could filter only those on 'chrome://settings', but
like barely anybody does anything other than the typical flow.

i really don't think we need to care about differentiating md-settings nor
settings-frame

[dpapad, 2017/03/04 02:54:05]

SGTM. I did not know we can filter by URL.

+    });
     // Preload bold Roboto so it doesn't load and flicker the first time used.
     document.fonts.load('bold 12px Roboto');
     settings.setGlobalScrollTarget(this.$.headerPanel.scroller);