Seems navigation-related. 

Can not reproduce with ToT on iOS 12. Marking as Fixed so test team can verify.

Still reproduced for me on iPhoneX, iOS 12.0 beta#9 M70.0.3529.0 canary
Same steps originally reported. Let me know if you need any info.

Sorry. It is indeed reproducible. 

So after step (3) WKWebView.hasOnlySecureContent returns NO (same as desktop Chrome).

and after step (5) WKWebView.hasOnlySecureContent still returns NO 

I think the fact that hasOnlySecureContent does not change after going back is fine, because the page is retrieved from page cache. Emily, we could file radar for this bug, but which argument we should use to convince Apple that WKWebView should recalculate WKWebView.hasOnlySecureContent property? 

CCing Security UX folks for comment #6

Hmm, on Chrome 72 on iOS 12.0 I'm seeing the HTTP image loaded from page cache on a back/forward navigation, so I would _expect_ WKWebView.hasOnlySecureContent to still return NO and for us to keep the downgraded indicator.

If I add a few more navigations on the stack after (for example, trigger the mixed content image downgrade, then navigate to example.org, bbc.com, badssl.com, so that the mixed-content-test.appspot.com page gets evicted from page cache) and then go back to the test page, the page cache no longer contains the HTTP image and the page is no longer downgraded (it correctly displays the lock icon).

Thanks Chris! Should we consider this behavior as WAI?

Ahh sorry, I missed step (3) in the original reproduction steps (which removes the HTTP image from the page). I _can_ reproduce this.

I think if we were to make a feature request, maybe it would be to give a way for embedders of WKWebView to trigger the recalculation (but given the relatively high-level visibility WKWebView gives us for mixed content, this might be unlikely).

For mixed content, if the rest of the state of the page is maintained in memory (and not reloaded from disk cache and re-created), then I think there is an argument that the state of the page is still tainted by the previous mixed content (this is the same reason why we don't un-downgrade the page after step (3) in the original report when the HTTP image has been swapped for the HTTPS image). For example, there could be JS state that includes data from the image.

While this is not really obvious to users, I think I lean toward treating this as okay behavior (even if it's potentially a little overly cautious, since in most cases the image likely won't taint the page after it is replaced). Reloading the page will make the downgraded indicator go away.

Am I correct in my understanding of how the back/forward loading from memory works (i.e., that it does not re-create the page, it is loading the exact prior state of the tab/dom/JS context)?

Thank you Chris! Your understanding of back-forward navigation is correct. Based on your detailed feedback, I'm closing this bug.