Bug 55473 – [GTK] Add support for external protocol handlers

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Sergio Villar Senin]

In order to do that we need:
   * Some way to disable the default  handling of about: protocols in webcore (by default about: means empty document)
   * WebKitGtk+ API to disable the about: default behaviour commented above

[Sergio Villar Senin]

Created attachment 84235 [details]
Patch

[Martin Robinson]

Comment on attachment 84235 [details]
Patch

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

Instead of adding new API (though perhaps we still want to), would it make sense to just query soup for an installed "about:" handler while handling a request. If the handler is installed then remove it from the empty document schemas.

What does Chromium do to get around the empty document scheme issue?

> Source/WebKit/gtk/webkit/webkitglobals.cpp:220
> +void webkit_register_url_scheme_as_local (const gchar* scheme)
> +{
> +    webkitInit();
> +    SchemeRegistry::registerURLSchemeAsLocal(String::fromUTF8(scheme));
> +}
> +
> +void webkit_remove_url_scheme_registered_as_local (const gchar* scheme)
> +{
> +    webkitInit();
> +    SchemeRegistry::removeURLSchemeRegisteredAsLocal(String::fromUTF8(scheme));
> +}
> +
> +void webkit_register_url_scheme_as_empty_document (const gchar* scheme)
> +{
> +    webkitInit();
> +    SchemeRegistry::registerURLSchemeAsEmptyDocument(String::fromUTF8(scheme));
> +}
> +
> +void webkit_remove_url_scheme_registered_as_empty_document (const gchar* scheme)
> +{
> +    webkitInit();
> +    SchemeRegistry::removeURLSchemeRegisteredAsEmptyDocument(String::fromUTF8(scheme));
> +}

extra space after the function names.

[Sergio Villar Senin]

(In reply to comment #2)
> (From update of attachment 84235 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=84235&action=review
> 
> Instead of adding new API (though perhaps we still want to), would it make sense to just query soup for an installed "about:" handler while handling a request. If the handler is installed then remove it from the empty document schemas.

That's indeed possible. I went for the new API approach because all the other ports offer that API, so I thought it'd be sensible to have it also in WebKitGtk+.

> What does Chromium do to get around the empty document scheme issue?

I didn't check that but Dan commented once that they just don't issue the request to webkit and handle it all at browser's level.

[Eric Seidel (no email)]

I'm really not the protocol expert.

[Sergio Villar Senin]

(In reply to comment #2)
> (From update of attachment 84235 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=84235&action=review
> 
> Instead of adding new API (though perhaps we still want to), would it make sense to just query soup for an installed "about:" handler while handling a request. If the handler is installed then remove it from the empty document schemas.

BTW forget about my answer, I missunderstood what you meant. What you suggest isn't possible because the request does not even reach the platform network layer as it's handled internally by WebCore.

[Martin Robinson]

(In reply to comment #5)
> > Instead of adding new API (though perhaps we still want to), would it make sense to just query soup for an installed "about:" handler while handling a request. If the handler is installed then remove it from the empty document schemas.
> BTW forget about my answer, I missunderstood what you meant. What you suggest isn't possible because the request does not even reach the platform network layer as it's handled internally by WebCore.

I guess this could be handled in the WebKit layer. Perhaps FrameLoaderClient allows some access.

[Adam Barth]

Comment on attachment 84235 [details]
Patch

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

> Source/WebCore/platform/SchemeRegistry.cpp:82
> +    DEFINE_STATIC_LOCAL(bool, firstTime, (true));

I don't think this is needed for primitive types.

[Adam Barth]

Comment on attachment 84235 [details]
Patch

This isn't really a good idea.  That about scheme is super magical.  Putting non-empty documents in the about scheme doesn't really work.

The about:blah URLs in Chrome are handled by the embedder.  Typically, they're either translated to a data URL for WebKit or to another internal URL in the "chrome" scheme.

[Sergio Villar Senin]

(In reply to comment #8)
> (From update of attachment 84235 [details])
> This isn't really a good idea.  That about scheme is super magical.  Putting non-empty documents in the about scheme doesn't really work.

Just for the sake of knowing a bit more about WebCore guts, what is special about the "about:" protocol? What kind of tricky stuff does it?

> The about:blah URLs in Chrome are handled by the embedder.  Typically, they're either translated to a data URL for WebKit or to another internal URL in the "chrome" scheme.

Ok, I'll follow that approach then. Thanks for reviewing.

[Sergio Villar Senin]

Renaming the bug title. We're not going to change the "about:" behaviour but we still need to allow external protocol handlers. In order to do that we have to allow clients to create their own SoupRequesters that will be used to register new protocols.

[Sergio Villar Senin]

Created attachment 84384 [details]
Patch

I just kept the ResourceHandleSoup part of the original patch.

[Sergio Villar Senin]

Comment on attachment 84384 [details]
Patch

Clearing flags on attachment: 84384

Committed r80143: <http://trac.webkit.org/changeset/80143>

[Sergio Villar Senin]

All reviewed patches have been landed.  Closing bug.

[Adam Barth]

> Just for the sake of knowing a bit more about WebCore guts, what is special about the "about:" protocol? What kind of tricky stuff does it?

Some examples:

1) Loads of about: URLs are synchronous instead of asynchronous.
2) about: URLs inherit the security context of their parent (or opener if there isn't a parent).
3) about: URLs are used internally by the WebKit in various situations where having a non-empty document would be problematic (e.g., frame initialization and in the XSS filter).

(2) is really scary if about: URLs start containing anything besides the empty document.