Since r181134 we are now blocking mixed content by default (except for images if I understood the patch correctly, where we still show a warning in the console message, and the client is notified), which is indeed good news. The test is only failing for the run-insecure-content, not the display one because it uses an image. So, we should probably check now that the load failed in provisional load state. The thing is, since we don't expose the allowDisplayOfInsecureContent nor the allowRunningOfInsecureContent settings in the API, WEBKIT_INSECURE_CONTENT_RUN is now impossible to happen. Fortunately we didn't document any default policy in our API docs, so we can just change it, but I think we should document the new behaviour, explaining that running insecure content is always blocked, that WEBKIT_INSECURE_CONTENT_RUN is deprecated, so WebKitWebView::insecure-content-detected will only be called with WEBKIT_INSECURE_CONTENT_DISPLAYED and only for images, because all other contents will be blocked producing a load failure of the resource. Or we could expose the settings in our API, and keeping our current unit tests but enabling the settings (I would still keep the setting disabled by default in this case, even if it's not backwards compatible).