Fixed this in https://codereview.chromium.org/2408393003. The corresponding WebContents methods still need to be renamed though.

I'm starting a CL (https://crrev.com/c/729497) to handle renaming these methods. Due to these being overridden virtual methods, this involves going up the class hierarchy to also rename methods for RenderFrameHostDelegate.

Separately, on the other side of the FrameHostMsg_DidDisplayInsecureContent IPC, we have RenderFrameImpl, which in turn overrides blink::WebFrameClient. 
Similarly, WorkerFetchContextImpl sends IPCs (FrameHostMsg_DidRunInsecureContent), and it overrides blink::WebWorkerFetchContext.

My current CL avoids crossing the IPC boundary to keep the modules affected to a minimum. I can start a second CL on top of it that extends the renaming to everything on the other side as well (including the IPC message name). I'm not sure what a good "stopping point" is for a rename like this.


I also briefly looked into how far-reaching the "Insecure Content" nomenclature is, where "Mixed Content" might be more idiomatic. (This is likely a very-not-exhaustive list.)

In WebContentsImpl:
- PassiveInsecureContentFound()
- ShouldAllowRunningInsecureContent()

In WebPreferences:
- allow_running_insecure_content

How far do we want to take the renaming of these concepts? Is isolating it to the pieces that (eventually) call the SSLManager sufficient? Do we want to take on a broader renaming change?

I think ideally we'd rename all of those, but this is a pretty low-priority task that I suggested mostly just to get your feet wet with writing a CL and getting it reviewed. So I'd say do as much or as little of it as you feel like. If you don't do all of it, maybe the next new person will come along and they can finish it as their starter bug. :)