Add an histogram to differentiate between hang types of the renderer

content/browser/renderer_host/render_widget_host_delegate.h

Index: content/browser/renderer_host/render_widget_host_delegate.h
diff --git a/content/browser/renderer_host/render_widget_host_delegate.h b/content/browser/renderer_host/render_widget_host_delegate.h
index 6777b9c999261e7fc63cbc10a9d51c45dbc9a3ff..6593b826ea7c099f7b8e121cf58eb1da6fee510f 100644
--- a/content/browser/renderer_host/render_widget_host_delegate.h
+++ b/content/browser/renderer_host/render_widget_host_delegate.h
@@ -133,9 +133,25 @@ class CONTENT_EXPORT RenderWidgetHostDelegate {
   virtual RenderWidgetHostImpl* GetFocusedRenderWidgetHost(
       RenderWidgetHostImpl* receiving_widget);
 
+  // Enum used in histograms to differentiate between the different

[nasko, 2016/07/12 17:18:02]

nit: Enum is redundant, as it is obvious from the type definition below.

[clamy, 2016/07/13 10:02:21]

Done.

+  // types of renderer hang reported by
+  // RenderWidgetHostDelegate::RendererUnresponsive.
+  // Only add values at the end, do not delete values.

[nasko, 2016/07/12 17:18:02]

Does that mean we will keep this enum/UMA forever? Is it possible to use some
other mechanism which we aren't stuck with? Maybe DumpWithoutCrashing?

[Alexei Svitkine (slow), 2016/07/12 18:36:40]

You can always delete histograms. That's fine.

The point is you can't renumber an enum or re-use enum values (without at least
renaming the histogram), otherwise values will be inconsistent between versions.

[clamy, 2016/07/13 10:02:21]

I'm not sure how DumpWithoutCrashing works, and it's not very clear from the
description either. I need reports from the field on the distribution of the
different types of renderer hang, to see where the huge spike we're seeing is
coming from.

[nasko, 2016/07/15 17:32:08]

DumpWithoutCrashing literally does what it says - generates a crash report, as
thought we had a crash at the line we call it on, but doesn't really crash the
process itself. It is useful tool to debug issues that are hard to understand,
but it does add overhead.
Ah, good to know. Thanks!
Let's use a histogram then, as it doesn't have much overhead and we might want
to keep it for a while.

+  enum RendererUnresponsiveType {
+    RENDERER_UNRESPONSIVE_UNKNOWN = 0,
+    RENDERER_UNRESPONSIVE_IN_FLIGHT_EVENTS = 1,
+    RENDERER_UNRESPONSIVE_DIALOG_CLOSED = 2,
+    RENDERER_UNRESPONSIVE_DIALOG_SUPPRESSED = 3,
+    RENDERER_UNRESPONSIVE_BEFORE_UNLOAD = 4,
+    RENDERER_UNRESPONSIVE_UNLOAD = 5,
+    RENDERER_UNRESPONSIVE_CLOSE_PAGE = 6,
+    RENDERER_UNRESPONSIVE_MAX = RENDERER_UNRESPONSIVE_CLOSE_PAGE,
+  };
+
   // Notification that the renderer has become unresponsive. The
   // delegate can use this notification to show a warning to the user.
-  virtual void RendererUnresponsive(RenderWidgetHostImpl* render_widget_host) {}
+  virtual void RendererUnresponsive(RenderWidgetHostImpl* render_widget_host,
+                                    RendererUnresponsiveType type) {}
 
   // Notification that a previously unresponsive renderer has become
   // responsive again. The delegate can use this notification to end the