[Android] Add support for a hung renderer dialog

chrome/browser/android/hung_renderer_infobar_delegate.cc

+// Copyright 2015 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "chrome/browser/android/hung_renderer_infobar_delegate.h"
+
+#include "base/callback.h"
+#include "base/metrics/histogram.h"
+#include "chrome/grit/generated_resources.h"
+#include "components/infobars/core/infobar.h"
+#include "content/public/browser/render_process_host.h"
+#include "content/public/browser/web_contents.h"
+#include "content/public/common/result_codes.h"
+#include "grit/theme_resources.h"
+#include "ui/base/l10n/l10n_util.h"
+
+HungRendererInfoBarDelegate::HungRendererInfoBarDelegate(
+    content::WebContents* web_contents)
+    : web_contents_(web_contents), action_logged_for_uma_(false) {
+  DCHECK(web_contents);
+}
+
+HungRendererInfoBarDelegate::~HungRendererInfoBarDelegate() {
+  LogAction(REMOVE);

[Peter Kasting, 2015/09/01 22:24:05]

This is just browser shutdown, right?  Is logging this case really necessary? 
If so, something like "BROWSER_SHUTDOWN" would be a better name than "REMOVE".

[jdduke (slow), 2015/09/02 00:04:01]

You tell me =/. Is there anything else that could result in an infobar being
shutdown? I'll just call it INFOBAR_SHUTDOWN for now.

[Peter Kasting, 2015/09/02 21:52:45]

I wasn't thinking clearly.  This is tab closure, not browser shutdown (though
browser shutdown implies first closing all the tabs).  Maybe name this
TAB_CLOSED.

+}
+
+void HungRendererInfoBarDelegate::InfoBarDismissed() {
+  LogAction(DISMISS);
+}
+
+HungRendererInfoBarDelegate*
+HungRendererInfoBarDelegate::AsHungRendererInfoBarDelegate() {
+  return this;
+}
+
+int HungRendererInfoBarDelegate::GetIconID() const {
+  return IDR_INFOBAR_FROZEN_TAB;
+}
+
+base::string16 HungRendererInfoBarDelegate::GetMessageText() const {
+  return l10n_util::GetPluralStringFUTF16(IDS_BROWSER_HANGMONITOR_RENDERER, 1);
+}
+
+base::string16 HungRendererInfoBarDelegate::GetButtonLabel(
+    InfoBarButton button) const {
+  return l10n_util::GetStringUTF16((button == BUTTON_OK)
+                                       ? IDS_BROWSER_HANGMONITOR_RENDERER_END
+                                       : IDS_BROWSER_HANGMONITOR_RENDERER_WAIT);
+}
+
+bool HungRendererInfoBarDelegate::Accept() {
+  LogAction(KILL);
+  content::RenderProcessHost* process = web_contents_->GetRenderProcessHost();
+  process->Shutdown(content::RESULT_CODE_HUNG, false);
+  return true;
+}
+
+bool HungRendererInfoBarDelegate::Cancel() {
+  LogAction(WAIT);
+  return true;
+}
+
+void HungRendererInfoBarDelegate::OnRendererResponsive() {
+  LogAction(RESPONSIVE);
+}
+
+void HungRendererInfoBarDelegate::LogAction(Action action) {
+  if (action_logged_for_uma_)

[Peter Kasting, 2015/09/01 22:24:05]

The only reason we should get multiple actions logged is because of the call in
the destructor, right?  So if that goes away, this could go away, and if it
doesn't, it seems like this conditional could move to guard that call, making it
clearer what the source of dupe logging calls would be.

[jdduke (slow), 2015/09/02 00:04:01]

Done.

+    return;
+
+  action_logged_for_uma_ = true;
+  UMA_HISTOGRAM_ENUMERATION("HungRenderer.MobileInfoBar.Action", action,
+                            ACTION_COUNT);
+}