Fix broken mixed script Rappor metric and add browser test

chrome/renderer/content_settings_observer.cc

Index: chrome/renderer/content_settings_observer.cc
diff --git a/chrome/renderer/content_settings_observer.cc b/chrome/renderer/content_settings_observer.cc
index 8bf046741d65ffa0b06a4183bd22d5d53de35c2c..ac80ba79c89cbe1cc78e7b7ae7cec6e8143e5bc8 100644
--- a/chrome/renderer/content_settings_observer.cc
+++ b/chrome/renderer/content_settings_observer.cc
@@ -483,7 +483,7 @@ bool ContentSettingsObserver::allowRunningInsecureContent(
     SendInsecureContentSignal(INSECURE_CONTENT_RUN_SWF);
 
   if (!allow_running_insecure_content_ && !allowed_per_settings) {
-    DidBlockContentType(CONTENT_SETTINGS_TYPE_MIXEDSCRIPT, origin.host());
+    DidBlockContentType(CONTENT_SETTINGS_TYPE_MIXEDSCRIPT, origin.toString());

[sky, 2016/06/16 16:22:47]

I'm not familiar with this code, so why is toString better than host? A comment
would help. What is the expectation for the argument supplied to
DidBlockContentType? A comment in the header would be helpful.

[estark, 2016/06/16 16:56:58]

The browser-side IPC handler expects |details| to be a valid GURL for this
content type (and a hostname is not a valid GURL). Added comments.

[sky, 2016/06/16 17:42:49]

Can DidBlockContentType take a GURL then? Also, it's my understanding toString()
may not return a url. It returns something 'like' a url. For if the
websecurityorigin is empty toString() returns 'null'. How do you know you won't
hit that code path?

[estark, 2016/06/16 18:29:23]

Ah, that's a good point. It appears that this could indeed be empty if the
origin is, for example, sandboxed. My understanding, also, is that this string
argument is a generic details argument that can't simply be changed to a GURL.
(Other content settings type send other string values in the |details| argument,
IIUC.)

I don't think I can spend any more time on this. lgarron and/or jialiul, since
you did the original metric + fix, are either of you interested in taking this
over, now that there's a test for it?

Otherwise I think we should just revert the commit that introduced this metric
until someone has time to fix it properly.

[Jialiu Lin, 2016/06/16 20:47:17]

Here is the CL originally introduced this rappor metric.
https://codereview.chromium.org/1162123002
If nobody is actually consuming this rappor metric, I agree with estark that we
probably should simply revert it.

     return false;
   }