Adapt MixedContentChecker for remote frames

third_party/WebKit/LayoutTests/http/tests/security/mixedContent/strict-mode-image-in-frame-blocked.https-expected.txt

-CONSOLE ERROR: Mixed Content: The page at 'https://127.0.0.1:8443/security/mixedContent/resources/frame-with-insecure-image.html' was loaded over HTTPS, but requested an insecure image 'http://127.0.0.1:8080/security/resources/compass.jpg'. This request has been blocked; the content must be served over HTTPS.
+CONSOLE ERROR: Mixed Content: The page at 'https://127.0.0.1:8443/security/mixedContent/strict-mode-image-in-frame-blocked.https.html' was loaded over HTTPS, but requested an insecure image 'http://127.0.0.1:8080/security/resources/compass.jpg'. This request has been blocked; the content must be served over HTTPS.

[jochen (gone - plz use gerrit), 2016/01/25 11:33:29]

this expectation update looks odd - from the CL description, I would have
expected something like https://127.0.0.1:8443/ was loaded over HTTPS (i.e. just
the origin), but instead, it's a different URL?

[estark, 2016/01/25 16:21:06]

Hmm, yes, there are a couple different things going on here, which I'll try to
explain here to see if they make sense:

First, we only would print the origin if the mixed frame (the frame with respect
to which we are considering the content mixed, i.e. the |mixedFrame| variable in
MixedContentChecker) was a cross-site OOPIF; otherwise it's a local frame and we
have access to the full URL. Since it's not OOP in the layout test, the test
prints the whole URL, not just the origin. Though, now come to think of it,
maybe we should always just print the origin for consistency in both
site-isolated and not-site-isolated worlds.

Second, I did change which URL gets printed, which is why the URL changed here.
The old MixedContentChecker used |frame| to retrieve the main resource URL to
print in this message, whereas the new MixedContentChecker uses |mixedFrame| --
the frame with respect to which we are considering the content mixed. In the old
world, it could get weird because if https://a.com embeds http://b.com which
loads http://b.com/foo.jpg, the image would have been considered mixed content
with respect to the top-level frame (https://a.com) but we would have printed a
confusing message about the embedded frame: "The page at http://b.com was loaded
over HTTPS but requested an insecure image...". So I thought it made more sense
to print the top-level frame.

Another approach might be to say that once a frame loads as mixed content, we
don't need to print console messages about every subresource inside the frame
also being mixed content. So we would continue to use the frame that actually
requested the resource to get the URL for the console message, but we wouldn't
print the message when the subresource is not considered mixed content with
respect to that frame.

 This test passes if the image in the frame below is treated as blockable content.