Reland "Use last committed origin to track active content with cert errors"
This is a reland of b2a162185efb407d7c96800de9dec50333420652
The original change introduced a test which was (I believe) flaking
because a favicon request could cause the navigation entry to get
marked as having run insecure content. (Favicons are treated as
active content like scripts, because they're unusually powerful
images that show up in browser UI.)
Original change's description:
> Use last committed origin to track active content with cert errors
>
> This is a speculative fix for a test flake that I can't reproduce
> locally or on trybots.
>
> Previously, when a page loaded an active subresource with a cert error,
> we were using the *visible* navigation entry to compute the
> origin to mark as insecure. My theory is that the visible navigation
> entry might not correspond to the document that actually loaded the
> subresource. In the flaky test, we load a page with a cert error, and
> then navigate back. The page with a cert error triggers a favicon
> request (we treat favicons as active subresources even though they are
> just images), and I think (?) it's possible that this insecure favicon
> resource will be processed by SSLManager after the back navigation has
> changed the visible entry, therefore marking the page we're going back
> to as insecure even though it shouldn't be affected.
>
> This speculative fix drops the code that computes an origin from the
> visible navigation entry and passes that into SSLManager (and also
> drops a couple obsolete TODOs alongside it). Instead, we look at the
> committed entry's origin and mark that origin as insecure.
>
> Bug: 638576
> Change-Id: Ief60adf121261a7021bf5be6c196d5c065b06663
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2218545
> Reviewed-by: Alex Moshchuk <[email protected]>
> Reviewed-by: Carlos IL <[email protected]>
> Commit-Queue: Emily Stark <[email protected]>
> Cr-Commit-Position: refs/heads/master@{#775122}
Bug: 638576
Change-Id: I4a689ac911d05360ec29b48c18d28e16d719648d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2231807
Reviewed-by: Alex Moshchuk <[email protected]>
Commit-Queue: Emily Stark <[email protected]>
Cr-Commit-Position: refs/heads/master@{#775408}
diff --git a/content/browser/web_contents/web_contents_impl.cc b/content/browser/web_contents/web_contents_impl.cc
index 1c436a8..4fdf8cf 100644
--- a/content/browser/web_contents/web_contents_impl.cc
+++ b/content/browser/web_contents/web_contents_impl.cc
@@ -4796,15 +4796,22 @@
void WebContentsImpl::OnDidRunContentWithCertificateErrors(
RenderFrameHostImpl* source) {
- // TODO(nick, estark): Do we need to consider |source| here somehow?
- NavigationEntry* entry = controller_.GetVisibleEntry();
- if (!entry)
+ // For RenderFrameHosts that are inactive and going to be discarded, we can
+ // disregard this message; there's no need to update the UI if the UI will
+ // never be shown again.
+ //
+ // We still process this message for speculative RenderFrameHosts. This can
+ // happen when a subframe's main resource has a certificate error. The
+ // currently committed navigation entry will get marked as having run insecure
+ // content and that will carry over to the navigation entry for the
+ // speculative RFH when it commits.
+ if (source->lifecycle_state() !=
+ RenderFrameHostImpl::LifecycleState::kSpeculative &&
+ source->IsInactiveAndDisallowReactivation()) {
return;
-
- // TODO(estark): check that this does something reasonable for
- // about:blank and sandboxed origins. https://crbug.com/609527
+ }
controller_.ssl_manager()->DidRunContentWithCertErrors(
- entry->GetURL().GetOrigin());
+ source->GetMainFrame()->GetLastCommittedOrigin().GetURL());
}
void WebContentsImpl::DOMContentLoaded(RenderFrameHost* render_frame_host) {
