Downgrade lock icon for broken-HTTPS subresources

content/renderer/render_frame_impl.h

Index: content/renderer/render_frame_impl.h
diff --git a/content/renderer/render_frame_impl.h b/content/renderer/render_frame_impl.h
index bd386d4bcae542ffbe090621683a606c1b699a19..0d8c4053cd49b077887abac1250c6ed1b8420b9f 100644
--- a/content/renderer/render_frame_impl.h
+++ b/content/renderer/render_frame_impl.h
@@ -519,6 +519,13 @@ class CONTENT_EXPORT RenderFrameImpl
   void didDisplayInsecureContent() override;
   void didRunInsecureContent(const blink::WebSecurityOrigin& origin,
                              const blink::WebURL& target) override;
+  void didDisplayContentWithCertificateErrors(
+      const blink::WebURL& url,
+      const blink::WebCString& security_info) override;

[jww, 2015/11/20 01:25:08]

Why are these WebCStrings instead of WebStrings? I don't see WebCStrings passed
around very much.

[estark, 2015/11/23 23:40:24]

I was going off of other APIs that expose security_info, which is an opaque
serialized blob of data, e.g.
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...
and
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...

I'm not sure why these existing APIs used WebCString though. Any thoughts?

[jww, 2015/11/25 19:24:02]

Nope, not really. Can you email chromium-dev or blink-dev to try and figure out
why we would use one over the other? I don't care too much, though, so we don't
need to block on that.

+  void didRunContentWithCertificateErrors(
+      const blink::WebSecurityOrigin& origin,
+      const blink::WebURL& url,
+      const blink::WebCString& security_info) override;
   void didChangePerformanceTiming() override;
   void didAbortLoading(blink::WebLocalFrame* frame) override;
   void didCreateScriptContext(blink::WebLocalFrame* frame,