146157 2015-06-19 13:18:26 -0700 PageLoadState::didCommitLoad should not have hasInsecureContent parameter 2015-06-20 07:15:53 -0700 1 1 1 Unclassified WebKit WebKit2 528+ (Nightly build) All All RESOLVED INVALID https://bugs.webkit.org/show_bug.cgi?id=142461 P2 Normal --- 1 mcatanzaro webkit-unassigned mcatanzaro mitz sam oldest_to_newest 1103377 0 mcatanzaro 2015-06-19 13:18:26 -0700 hasInsecureContent is not an accurate name for the new parameter to PageLoadState::didCommitLoad: the only reason it could be true is if the certificate uses a SHA1 signature, so hasInsecureContent will usually be *false* if the certificate is insecure. We should fix that. I don't have a great alternative name, but one possibility is hasDubiouslySecureContent, since "dubious" is often used to indicate that the security is acceptable (we're not going to block the connection) but not good. This isn't a great name either, but it's much better, since this code cannot ever block any content. 1103400 1 mcatanzaro 2015-06-19 13:56:54 -0700 Turns out that we can just remove this parameter, because it is redundant with PageLoadState::didDisplayOrRunInsecureContent. (Actually it is a bit more powerful, in that it allows the state to be changed from insecure to secure, but that's probably something we never want to do.) And I will do so in my patch for bug #146159, so I created one too many bugs. 1103610 2 mcatanzaro 2015-06-20 07:15:53 -0700 I've been thinking about this more. It's hard to think of a good alternative name for this parameter, and in a certain sense it does exactly what it says: the PageLoadState _at the time of the call_ will be reset to either secure or insecure, and if set to secure it will simply be changed to insecure a bit later down the road. This is confusing, but the current code is probably best so long as we're performing extra security checks in WebPageProxy (not ideal).