The consensus on IRC #webkitgtk+ and the bug is that the permission-request model isn't a good fit for this particular issue, summarised by Gustavo:
> So, here's my opinion after understanding how this works: the permission > request APIs we currently have are also in a way actions - when you allow a > geolocation request webcore will go ahead and provide proceed with obtaining > the location, when you deny it, webcore will tell the backend it's denied, > and the content will be able to show an error. I think it would be bad to > reuse these methods with such a different meaning and requiring the API user > to take a second action after using them. The current insecure-content-detected notification is probably a better approach to follow, so I'm proposing a new signal "tls-errors", to be emitted as a notification along with a WebKitTLSErrorsInfo object when there are TLS errors and the policy is WEBKIT_TLS_ERRORS_POLICY_FAIL (no new policy is required). The WebKitTLSErrorsInfo object would have this API to find out more about the reasons for failure: WEBKIT_API GTlsCertificate * webkit_tls_errors_info_get_certificate (WebKitTLSErrorsInfo *info); WEBKIT_API GTlsCertificateFlags webkit_tls_errors_info_get_tls_errors (WebKitTLSErrorsInfo * info); WEBKIT_API const gchar * webkit_tls_errors_info_get_host (WebKitTLSErrorsInfo * info); The user agent can allow errors on subsequent loads for this host to be ignored through a new public API for WebKitWebContext: void webkit_web_context_allow_specific_https_certificate_for_host(WebKitWebContext* context, GtlCertificate* certificate, const char* host). Thoughts and feedback? Brian _______________________________________________ webkit-gtk mailing list webkit-gtk@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-gtk
