[Contextual Search] Add metrics for Resolve and View timing

chrome/android/java/src/org/chromium/chrome/browser/contextualsearch/ContextualSearchUma.java

Index: chrome/android/java/src/org/chromium/chrome/browser/contextualsearch/ContextualSearchUma.java
diff --git a/chrome/android/java/src/org/chromium/chrome/browser/contextualsearch/ContextualSearchUma.java b/chrome/android/java/src/org/chromium/chrome/browser/contextualsearch/ContextualSearchUma.java
index f10f973bee79645bda12d96c1c4437adab6456c4..7019f8be407710c9a5c62cb1b35b37f6d1de8372 100644
--- a/chrome/android/java/src/org/chromium/chrome/browser/contextualsearch/ContextualSearchUma.java
+++ b/chrome/android/java/src/org/chromium/chrome/browser/contextualsearch/ContextualSearchUma.java
@@ -706,6 +706,28 @@ public class ContextualSearchUma {
     }
 
     /**
+     * Logs the duration from starting a search until the Search Term is Resolved.
+     * @param durationMs The duration to record.
+     */
+    public static void logSearchTermResolution(long durationMs) {

[pedro (no code reviews), 2016/02/26 22:30:09]

Nit: logSearchTermResolution --> logSearchTermResolutionDuration?

[Donn Denman, 2016/02/27 00:18:40]

Done.

+        RecordHistogram.recordMediumTimesHistogram(
+                "Search.ContextualSearchResolutionDuration", durationMs, TimeUnit.MILLISECONDS);
+    }
+
+    /**
+     * Logs the duration from starting a search until the results in the SERP start to become
+     * viewable. Should be called only for searches that are prefetched.
+     * @param durationMs The duration to record.
+     * @param didResolve Whether a Search Term Resolution was required as part of the loading.
+     */
+    public static void logSearchResultsViewable(long durationMs, boolean didResolve) {
+        String histogramName = didResolve ? "Search.ContextualSearchResolvedResultsViewableDuration"
+                                          : "Search.ContextualSearchLiteralResultsViewableDuration";

[pedro (no code reviews), 2016/02/26 22:30:10]

I thought "literal" / verbatim results were never prefetched. Isn't this true?
If that's true, then passing the didResolve boolean is not necessary.

[Donn Denman, 2016/02/27 00:18:39]

No, with the opt-out on HTTPS pages we usually do a literal search but we want
to prefetch the results for a quick-viewing experience.

[pedro (no code reviews), 2016/02/27 00:39:04]

I see. In this case, nevermind.

+        RecordHistogram.recordMediumTimesHistogram(
+                histogramName, durationMs, TimeUnit.MILLISECONDS);
+    }
+
+    /**
      * Logs whether the promo was seen.

[pedro (no code reviews), 2016/02/26 22:30:09]

Shouldn't we also log the time it takes to establish a selection? Currently, the
selection is the first feedback we give to users that something is happening,
and with the single request model, we'll postpone that until we get single
request response. I'd be interested to know for how long we'll delay that
feedback in the new model.

[Donn Denman, 2016/02/27 00:18:39]

Are you asking about the initial selection that happens when you tap, or the
time until we extend the selection to the search term?  The former is not
affected by Single-request.  The latter should be exactly the same as the
resolve timing, because the selection adjustment is computed from the resolved
term.  Am I missing something?

[pedro (no code reviews), 2016/02/27 00:39:04]

Yes, I'm asking about the initial selection. I thought we were considering not
doing the initial selection, so we could prevent it from triggering a search
depending on the server's response.

[Donn Denman, 2016/02/29 17:54:11]

The idea of not establishing an initial selection is part of the "New Tap
Feedback", which still has not been prototyped, so we're a long way from
building that.  No harm checking though! 

      * Logs multiple histograms, with and without the original triggering gesture.
      * @param wasPanelSeen Whether the panel was seen.