Bring up a content settings icon for ungestured registerProtocolHandler call.

content/renderer/render_view_impl.cc

Index: content/renderer/render_view_impl.cc
diff --git a/content/renderer/render_view_impl.cc b/content/renderer/render_view_impl.cc
index 16837b999eba5b00df72bfdb3b9f3f2e62772dfc..93ed5d2a8cd2f79137f3aee120dd3e28d0084107 100644
--- a/content/renderer/render_view_impl.cc
+++ b/content/renderer/render_view_impl.cc
@@ -5558,6 +5558,7 @@ void RenderViewImpl::registerProtocolHandler(const WebString& scheme,
   if (base.GetOrigin() != absolute_url.GetOrigin()) {
     return;
   }
+  LOG(INFO) << "Got RPH in RenderViewImpl";

[koz (OOO until 15th September), 2012/06/21 01:50:53]

Don't forget to remove this.

[Greg Billock, 2012/06/21 19:59:11]

I won't. There looks like a race bug, at least on linux. Without this line, an
ungestured RPH call in the page's onload() handler almost never gets through to
the browser to be handled. With this call, it almost always does get through. I
emailed Ben about this, but do you know how this can be fixed?

[koz (OOO until 15th September), 2012/06/21 23:03:50]

That's strange. I wonder if something changed recently in this area because RPH
is usually called onload() currently (eg: by calendar). Does it happen before
this patch?

[Greg Billock, 2012/06/21 23:10:59]

Yes. It was happening when I was testing the user gesture stuff, before any of
this.

On 2012/06/21 23:03:50, koz wrote:

[koz (OOO until 15th September), 2012/06/22 00:41:14]

I'm not sure why this would be failing. Recently the unit tests for this class
became really flaky on linux and chromeos, but I haven't seen any changes that
might have caused that.

[Greg Billock, 2012/06/22 19:45:40]

Looks like this is a prerendering thing. Proper threads/bugs opened.

   Send(new ViewHostMsg_RegisterProtocolHandler(routing_id_,
                                                UTF16ToUTF8(scheme),
                                                absolute_url,