Track mixed content by origin, not by URL
When a page runs active mixed content (or an active resource loaded with a certificate error), the origin's host is marked in SSLHostStateDelegate. The SSLHostStateDelegate is then queried to set mixed content flags on the NavigationEntry, which feeds into the SecurityLevel of the page. Before this CL, the host of the NavigationEntry's URL was being used to query SSLHostStateDelegate, but this means that mixed content flags weren't being set correctly for pages where the URL didn't match the actual origin (for example, about:blank). This CL changes SSLManager to query SSLHostStateDelegate with the committed origin of the root FrameNavigationEntry instead of the URL. As noted in the test in this CL, mixed content is still not being tracked properly for the initial about:blank navigation in a window or frame. That is tracked in https://crbug.com/1038765. This change creates a slightly weird UI; when an about:blank page is marked with active mixed content, the "about:" part is crossed-out (as seen in https://crbug.com/526218). A follow-up CL will fix that by only striking-through https:// schemes in the omnibox. Bug: 609527 Change-Id: Ia0f13290a5769006edea3719642a11faefe9ae8d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1986189 Commit-Queue: Emily Stark <estark@chromium.org> Reviewed-by:Mustafa Emre Acer <meacer@chromium.org> Cr-Commit-Position: refs/heads/master@{#728294}
Showing
Please register or sign in to comment