| Summary: | [GTK] Add WebKitWebResource::failed-with-tls-errors signal | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Carlos Garcia Campos <cgarcia> | ||||
| Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | berto, commit-queue, gustavo, mcatanzaro, mrobinson, pnormand, svillar | ||||
| Priority: | P2 | Keywords: | Gtk | ||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Attachments: |
|
||||||
|
Description
Carlos Garcia Campos
2014-10-19 01:44:17 PDT
Created attachment 240084 [details]
Patch
Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See http://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API Comment on attachment 240084 [details]
Patch
For compatibility's sake, it sounds like we should also emit the failed signal, or do you think that is not necessary?
(In reply to comment #3) > Comment on attachment 240084 [details] > Patch > > For compatibility's sake, it sounds like we should also emit the failed > signal, or do you think that is not necessary? This is different to the WebView signal. In the WebView signal you are supposed to be able to react to the signal, or ignore it. That's why it's boolean, you can handle it (to show the block page or whatever) or not, and if not handled, the default behaviour is to emit the failed signal, so that the normal failed handler will show the error page. In the case of resources, we don't have a default handler for load failures, the signal is only informative, you are not supposed to handle it or not. The GError passed to failed signal doesn't provide any additional information, you already know it's a TLS failure. Committed r175618: <http://trac.webkit.org/changeset/175618> |