|Summary:||PageLoadState::didCommitLoad should not have hasInsecureContent parameter|
|Product:||WebKit||Reporter:||Michael Catanzaro <mcatanzaro>|
|Severity:||Normal||CC:||mcatanzaro, mitz, sam|
|Version:||528+ (Nightly build)|
Description Michael Catanzaro 2015-06-19 13:18:26 PDT
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.
Comment 1 Michael Catanzaro 2015-06-19 13:56:54 PDT
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.
Comment 2 Michael Catanzaro 2015-06-20 07:15:53 PDT
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).