For consistency and because it's something expected and useful.
Created attachment 142688 [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 142688 [details] Patch The patch looks fine to me, but I am curious about the motivation. What does cancellation support really gain us in these cases? It looks like the only practical gain would be it would be possible to get a "cancelled" error after the async request is finished, since we are not checking for cancellation anywhere else that would avoid continued processing.
(In reply to comment #3) > (From update of attachment 142688 [details]) > The patch looks fine to me, but I am curious about the motivation. Mainly consistency, cancellable is something expected in functions using the gio async model. > What does cancellation support really gain us in these cases? It looks like the only practical gain would be it would be possible to get a "cancelled" error after the async request is finished, since we are not checking for cancellation anywhere else that would avoid continued processing. Other methods follow the approach of async method + signals, for example, cancelling a download operation emits the error signal with cancelled error. And we have specific APIs for it webkit_download_cancel. Something similar happens when loadingf something in a web view (load error signal + stop_load method). For methods using the gio async model, we provide the standard way, a cancellable object that allow the user to cancel the operation (and from any thread). When the user finishes the operation CANCELLED error is returned.
Comment on attachment 142688 [details] Patch OK, I guess we need cancellables anyway if we are to make the cancellation more useful in the future.
Committed r117735: <http://trac.webkit.org/changeset/117735>