Add UMA histograms to track very brief or frequent tabs and JS dialogs.

base/metrics/histogram_macros.h

Index: base/metrics/histogram_macros.h
diff --git a/base/metrics/histogram_macros.h b/base/metrics/histogram_macros.h
index 72f7d86167a58ece3497f86c8c9d0eec73475650..5ef1690b89c90dd7def96fa037b52c5d0aa225c4 100644
--- a/base/metrics/histogram_macros.h
+++ b/base/metrics/histogram_macros.h
@@ -182,6 +182,12 @@
     name, sample, base::TimeDelta::FromMilliseconds(1), \
     base::TimeDelta::FromHours(1), 100)
 
+// Use this macro to capture fine-grained timing variations from a millisecond
+// up to a minute, using 100 buckets.

[Ilya Sherman, 2016/01/26 22:39:04]

This description says that the lower bound is a millisecond, but it seems to be
100 microseconds.

[Joe Mason, 2016/01/27 16:51:21]

There's a design doc for this feature at
https://docs.google.com/document/d/14301hx1zc6qj9AXOoXqTnd-PwdGTECYBmkDE645P_kU/.
(See the start of the "Detailed Design" section.) The goal is to find out how
prevalent "abusive" popups are (eg. users being spammed with popups, or close
one tab and another immediately opens), and to try to find a more focused metric
on what counts as "abusive".

On 2016/01/26 22:39:04, Ilya Sherman wrote:
The intent of the comment is that this captures useful variations "around" one
millisecond. The smallest buckets are smaller than that so that, as the size
exponentially increases, we don't start getting buckets of 2, 4, 8 milliseconds
immediately. I wanted at least one bucket to capture "far below 1 msec" and one
to capture "a bit under 1 msec" before starting to grow into buckets that are
wider than 1 msec.

Starting at 500 msec would probably be fine enough to capture that distinction,
but once I decided not to use a standard macro I decided to err on the side of
being more fine grained, since it's easy to aggregate buckets during analysis.

The standard macro may work as well, but I don't want to prejudge the data so I
wanted to capture some very fine gradations just in case they turn out to be
relevant.

+#define UMA_HISTOGRAM_FINE_TIMES_100(name, sample) UMA_HISTOGRAM_CUSTOM_TIMES( \
+    name, sample, base::TimeDelta::FromMicroseconds(100), \
+    base::TimeDelta::FromMinutes(1), 100)

[Ilya Sherman, 2016/01/26 22:39:04]

I'm not sure that it makes sense to add this macro here, rather than using
UMA_HISTOGRAM_CUSTOM_TIMES from your calling code.  The time range covered by
this histogram is not too different from UMA_HISTOGRAM_TIMES.  (I'm curious,
actually, why you chose the specific bounds that you did.)

[Joe Mason, 2016/01/27 16:51:21]

Yeah, it's a judgement call - I thought it was a good idea because I'm using the
same parameters from 3 separate files in both chrome/ and components/, so the
use crosses enough boundaries to be worth putting in base/. I can repeat the
parameters in each file if you prefer.

[Ilya Sherman, 2016/01/28 05:25:26]

You could also define a macro in the component, and use that macro from the
//chrome layer as well.  I don't think this macro is different enough from
UMA_HISTOGRAM_TIMES to define in histogram_macros.h.

+
 #define UMA_HISTOGRAM_CUSTOM_TIMES(name, sample, min, max, bucket_count) \
     STATIC_HISTOGRAM_POINTER_BLOCK(name, AddTime(sample), \
         base::Histogram::FactoryTimeGet(name, min, max, bucket_count, \