Bug 127091 – [GTK] Implement custom URI schemes with CustomProtocols

• Component: WebKit2
• Status: RESOLVED FIXED

[Carlos Garcia Campos]

Since CustomProtocols implementation is common for the web and network processes, this will add support for custom uri schemes when using the network process.

[Carlos Garcia Campos]

Created attachment 221354 [details]
Patch

webkit_uri_scheme_request_get_web_view() is broken and always returns NULL. We need to find a way to bring it back.

[Carlos Garcia Campos]

Created attachment 221760 [details]
Rebased patch

[WebKit Commit Bot]

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

[WebKit Commit Bot]

Attachment 221760 [details] did not pass style-queue:


ERROR: Source/WebKit2/UIProcess/API/gtk/WebKitURISchemeRequest.cpp:154:  Use 0 or null instead of NULL (even in *comments*).  [readability/null] [4]
Total errors found: 1 in 11 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Carlos Garcia Campos]

Created attachment 221985 [details]
Rebased patch

[Gustavo Noronha (kov)]

Comment on attachment 221985 [details]
Rebased patch

View in context: https://bugs.webkit.org/attachment.cgi?id=221985&action=review

Is this holding something back? I guess we should figure out how to reimplement obtaining the originating webview or land this after we branch? LGTM otherwise.

> Source/WebKit2/UIProcess/API/gtk/WebKitWebContext.cpp:943
> -void webkitWebContextReceivedURIRequest(WebKitWebContext* context, WebKitURISchemeRequest* request)
> +void webkitWebContextStartLoadingCustomProtocol(WebKitWebContext* context, uint64_t customProtocolID, API::URLRequest* urlRequest)
>  {
> -    String scheme(String::fromUTF8(webkit_uri_scheme_request_get_scheme(request)));
> +    // FIXME: We need to figure out how to get the initiating page.

Is customProtocolID unique per requested load, or is that an id for the scheme? We could maintain a mapping of those IDs to pages, I guess.

[Carlos Garcia Campos]

(In reply to comment #6)
> (From update of attachment 221985 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=221985&action=review
> 
> Is this holding something back? I guess we should figure out how to reimplement obtaining the originating webview or land this after we branch? LGTM otherwise.

Yes, we need to find a solution for the initiating web view :-(

> > Source/WebKit2/UIProcess/API/gtk/WebKitWebContext.cpp:943
> > -void webkitWebContextReceivedURIRequest(WebKitWebContext* context, WebKitURISchemeRequest* request)
> > +void webkitWebContextStartLoadingCustomProtocol(WebKitWebContext* context, uint64_t customProtocolID, API::URLRequest* urlRequest)
> >  {
> > -    String scheme(String::fromUTF8(webkit_uri_scheme_request_get_scheme(request)));
> > +    // FIXME: We need to figure out how to get the initiating page.
> 
> Is customProtocolID unique per requested load, or is that an id for the scheme? We could maintain a mapping of those IDs to pages, I guess.

It's per request, yes, but it's generated by the networking process, and at this point in the web context we don't know the web view associated to this request ID to make a map.

[Carlos Garcia Campos]

Committed r162835: <http://trac.webkit.org/changeset/162835>