Bug 92749 - [WK2] Add Navigator Content Utils API support for WebKit2
Summary: [WK2] Add Navigator Content Utils API support for WebKit2
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Gyuyoung Kim
URL:
Keywords:
Depends on: 93081
Blocks: 92726 61838 93353
  Show dependency treegraph
 
Reported: 2012-07-31 07:11 PDT by Mikhail Pozdnyakov
Modified: 2019-06-05 23:30 PDT (History)
26 users (show)

See Also:


Attachments
preliminary patch (do not set any flags) (38.48 KB, patch)
2012-08-03 05:14 PDT, Mikhail Pozdnyakov
no flags Details | Formatted Diff | Diff
patch (38.81 KB, patch)
2012-08-08 03:49 PDT, Mikhail Pozdnyakov
gns: commit-queue-
Details | Formatted Diff | Diff
patch v2 (38.84 KB, patch)
2012-08-08 07:28 PDT, Mikhail Pozdnyakov
gns: commit-queue-
Details | Formatted Diff | Diff
patch v3 (44.82 KB, patch)
2012-08-08 14:34 PDT, Mikhail Pozdnyakov
no flags Details | Formatted Diff | Diff
patch v4 (44.78 KB, patch)
2012-08-13 13:50 PDT, Mikhail Pozdnyakov
no flags Details | Formatted Diff | Diff
patch v5 (42.83 KB, patch)
2012-08-27 03:34 PDT, Mikhail Pozdnyakov
no flags Details | Formatted Diff | Diff
Patch (44.34 KB, patch)
2013-07-31 05:14 PDT, Sanghyun Park
no flags Details | Formatted Diff | Diff
Patch (44.57 KB, patch)
2013-07-31 08:38 PDT, Sanghyun Park
no flags Details | Formatted Diff | Diff
Patch (39.93 KB, patch)
2015-05-11 01:01 PDT, Gyuyoung Kim
no flags Details | Formatted Diff | Diff
Patch (41.47 KB, patch)
2015-05-11 23:50 PDT, Gyuyoung Kim
no flags Details | Formatted Diff | Diff
Patch (41.29 KB, patch)
2015-07-02 21:04 PDT, Gyuyoung Kim
no flags Details | Formatted Diff | Diff
Patch (41.21 KB, patch)
2015-08-05 21:50 PDT, Gyuyoung Kim
beidson: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mikhail Pozdnyakov 2012-07-31 07:11:56 PDT
WK2 is missing Protocol Handler API.
Comment 1 Mikhail Pozdnyakov 2012-08-03 05:14:57 PDT
Created attachment 156332 [details]
preliminary patch (do not set any flags)

Register Protocol Handler implementation proposal
Comment 2 Mikhail Pozdnyakov 2012-08-08 03:49:10 PDT
Created attachment 157168 [details]
patch
Comment 3 Gustavo Noronha (kov) 2012-08-08 04:09:55 PDT
Comment on attachment 157168 [details]
patch

Attachment 157168 [details] did not pass gtk-ews (gtk):
Output: http://queues.webkit.org/results/13458218
Comment 4 Gyuyoung Kim 2012-08-08 04:24:17 PDT
Comment on attachment 157168 [details]
patch

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

> Source/WebKit2/UIProcess/WebRegisterProtocolHandlerProxy.messages.in:33
> +#endif

Missing // ENABLE(REGISTER_PROTOCOL_HANDLER).

> Source/WebKit2/WebProcess/WebCoreSupport/WebRegisterProtocolHandlerClient.cpp:69
> +

Nit : unneeded line.

> Source/WebKit2/WebProcess/WebCoreSupport/WebRegisterProtocolHandlerClient.cpp:70
> +#endif // ENABLE(CUSTOM_SCHEME_HANDLER)

Nit : It looks an empty line is needed.
Comment 5 Mikhail Pozdnyakov 2012-08-08 07:28:14 PDT
Created attachment 157215 [details]
patch v2

Fixed build failure on GTK. Gyuyoung, thanks for review!
Comment 6 Chris Dumez 2012-08-08 08:44:07 PDT
Comment on attachment 157215 [details]
patch v2

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

Looks like you're missing the integration with WebContext. You need to add some code in WebContext.cpp and WebContext.h to instantiate your new proxy and properly direct messages to it.

> Source/WebKit2/UIProcess/API/C/WKRegisterProtocolHandler.cpp:29
> +#include "WKAPICast.h"

This can be in the #if ENABLE(REGISTER_PROTOCOL_HANDLER) as well

> Source/WebKit2/UIProcess/API/C/WKRegisterProtocolHandler.cpp:35
> +using namespace WebKit;

Ditto
Comment 7 Gustavo Noronha (kov) 2012-08-08 09:13:33 PDT
Comment on attachment 157215 [details]
patch v2

Attachment 157215 [details] did not pass gtk-ews (gtk):
Output: http://queues.webkit.org/results/13461195
Comment 8 Chris Dumez 2012-08-08 09:21:45 PDT
Comment on attachment 157215 [details]
patch v2

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

> Source/WebKit2/GNUmakefile.list.am:1120
> +	Source/WebKit2/WebProcess/WebCoreSupport/WebRegisterProtocolHandlerClient.cpp \

You need to add DerivedSources/WebKit2/WebRegisterProtocolHandlerMessageReceiver.cpp to webkit2_built_sources as well.
Comment 9 Mikhail Pozdnyakov 2012-08-08 14:26:54 PDT
Comment on attachment 157215 [details]
patch v2

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

>> Source/WebKit2/GNUmakefile.list.am:1120
>> +	Source/WebKit2/WebProcess/WebCoreSupport/WebRegisterProtocolHandlerClient.cpp \
> 
> You need to add DerivedSources/WebKit2/WebRegisterProtocolHandlerMessageReceiver.cpp to webkit2_built_sources as well.

think this is done already..
Comment 10 Mikhail Pozdnyakov 2012-08-08 14:32:03 PDT
(In reply to comment #9)
> (From update of attachment 157215 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=157215&action=review
> 
> >> Source/WebKit2/GNUmakefile.list.am:1120
> >> +	Source/WebKit2/WebProcess/WebCoreSupport/WebRegisterProtocolHandlerClient.cpp \
> > 
> > You need to add DerivedSources/WebKit2/WebRegisterProtocolHandlerMessageReceiver.cpp to webkit2_built_sources as well.
> 
> think this is done already..

found a typo: WebRegisterProtocolHandlerMessageReceiver.cpp -> WebRegisterProtocolHandlerProxyMessageReceiver.cpp
Comment 11 Mikhail Pozdnyakov 2012-08-08 14:34:44 PDT
Created attachment 157300 [details]
patch v3

Chris, thank you for the review!
Comment 12 Gyuyoung Kim 2012-08-08 17:31:35 PDT
Comment on attachment 157300 [details]
patch v3

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

> Source/WebKit2/GNUmakefile.list.am:210
> +        DerivedSources/WebKit2/WebRegisterProtocolHandlerProxyMessageReceiver.cpp \

Nit : wrong indentation.

> Source/WebKit2/GNUmakefile.list.am:906
> +        Source/WebKit2/UIProcess/WebRegisterProtocolHandlerProvider.cpp \

ditto.

> Source/WebKit2/UIProcess/API/C/WKRegisterProtocolHandler.cpp:29
> +#if ENABLE(REGISTER_PROTOCOL_HANDLER)

It looks we don't need to add this macro to here.
Comment 13 Mikhail Pozdnyakov 2012-08-13 13:47:59 PDT
> > Source/WebKit2/UIProcess/API/C/WKRegisterProtocolHandler.cpp:29
> > +#if ENABLE(REGISTER_PROTOCOL_HANDLER)
> 
> It looks we don't need to add this macro to here.
This seems to be completely opposite to what was recommended in Comment #6 by Chris :) Do style guidelines tell anything about this?(I haven't found anything about it).
Comment 14 Mikhail Pozdnyakov 2012-08-13 13:50:05 PDT
Created attachment 158093 [details]
patch v4

Corrected indentation.
Comment 15 Chris Dumez 2012-08-13 13:52:52 PDT
Comment on attachment 158093 [details]
patch v4

LGTM.
Comment 16 Gyuyoung Kim 2012-08-13 18:18:50 PDT
LGTM too. Thanks.
Comment 17 Kenneth Rohde Christiansen 2012-08-14 05:05:05 PDT
Comment on attachment 158093 [details]
patch v4

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

> Source/WebKit2/CMakeLists.txt:276
> +    UIProcess/WebRegisterProtocolHandlerProvider.cpp

I find the name a big confusing. It sounds like a web-register and then it sounds like a function name instead of a class name. I think we can do better.

It feels really out of place with the other class names

> Source/WebKit2/ChangeLog:8
> +        Added support of Register Protocol Handler API.

Maybe link to http://www.w3.org/TR/html5/system-state-and-capabilities.html#custom-handlers

Also what about content handlers?

> Source/WebKit2/UIProcess/API/C/WKRegisterProtocolHandler.h:46
> +struct WKRegisterProtocolHandlerProvider {

Why is this a provider and not a Client?
Comment 18 Mikhail Pozdnyakov 2012-08-14 05:50:17 PDT
Comment on attachment 158093 [details]
patch v4

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

>> Source/WebKit2/CMakeLists.txt:276
>> +    UIProcess/WebRegisterProtocolHandlerProvider.cpp
> 
> I find the name a big confusing. It sounds like a web-register and then it sounds like a function name instead of a class name. I think we can do better.
> 
> It feels really out of place with the other class names

We currently have WebRegisterProtocolHandlerClient in WebProcess.. So I was following the naming that was already there..

>> Source/WebKit2/ChangeLog:8
>> +        Added support of Register Protocol Handler API.
> 
> Maybe link to http://www.w3.org/TR/html5/system-state-and-capabilities.html#custom-handlers
> 
> Also what about content handlers?

Sure, link will be useful. As for content handlers, WebKit does not expose JS API for it yet, think it is out of scope of this patch..

>> Source/WebKit2/UIProcess/API/C/WKRegisterProtocolHandler.h:46
>> +struct WKRegisterProtocolHandlerProvider {
> 
> Why is this a provider and not a Client?

Similar objects are called "providers" in Vibration API, Battery Status API and Geolocation API
Comment 19 Kenneth Rohde Christiansen 2012-08-14 05:57:15 PDT
(In reply to comment #18)
> (From update of attachment 158093 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=158093&action=review
> 
> >> Source/WebKit2/CMakeLists.txt:276
> >> +    UIProcess/WebRegisterProtocolHandlerProvider.cpp
> > 
> > I find the name a big confusing. It sounds like a web-register and then it sounds like a function name instead of a class name. I think we can do better.
> > 
> > It feels really out of place with the other class names
> 
> We currently have WebRegisterProtocolHandlerClient in WebProcess.. So I was following the naming that was already there..

OK then it is not your fault :-) I am just wondering why it is not called WebProtocolHandlerProvider or so. Why is the Register important? Maybe you cna find out who created the WebRegisterProtocolHandlerClient and ask.

> >> Source/WebKit2/ChangeLog:8
> >> +        Added support of Register Protocol Handler API.
> > 
> > Maybe link to http://www.w3.org/TR/html5/system-state-and-capabilities.html#custom-handlers
> > 
> > Also what about content handlers?
> 
> Sure, link will be useful. As for content handlers, WebKit does not expose JS API for it yet, think it is out of scope of this patch..

OK :-)

> 
> >> Source/WebKit2/UIProcess/API/C/WKRegisterProtocolHandler.h:46
> >> +struct WKRegisterProtocolHandlerProvider {
> > 
> > Why is this a provider and not a Client?
> 
> Similar objects are called "providers" in Vibration API, Battery Status API and Geolocation API

OK, if it is like that in WebKit2 then fine :-)
Comment 20 Mikhail Pozdnyakov 2012-08-22 12:02:37 PDT
Sam (or anyone), could you please take a look? it's been pending for a while..:(
Comment 21 Gyuyoung Kim 2012-08-22 16:47:17 PDT
I wonder if this patch is able to unskip tests related to protocol handler in WK2 layout test.

http://trac.webkit.org/browser/trunk/LayoutTests/platform/efl-wk2/TestExpectations#L45
Comment 22 Mikhail Pozdnyakov 2012-08-22 23:48:39 PDT
(In reply to comment #21)
> I wonder if this patch is able to unskip tests related to protocol handler in WK2 layout test.
> 
> http://trac.webkit.org/browser/trunk/LayoutTests/platform/efl-wk2/TestExpectations#L45

The dependent bug 92726 will.
Comment 23 Simon Hausmann 2012-08-24 03:26:01 PDT
Comment on attachment 158093 [details]
patch v4

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

> Source/WebKit2/UIProcess/API/C/WKRegisterProtocolHandler.h:38
> +    kWKCustomHandlersNew,
> +    kWKCustomHandlersRegistered,
> +    kWKCustomHandlersDeclined

The use of "Custom" in the name here seems "lonely" as it doesn not appear anywhere else in the API. How about kWKProtocolHandlerRegistrationStatus and kWKProtocolHandlerNew, kWKProtocolHandlerRegistered as well as kWKProtocolHandlerDenied?

> Source/WebKit2/UIProcess/API/C/WKRegisterProtocolHandler.h:59
> +WK_EXPORT void WKRegisterProtocolHandlerSetProvider(WKRegisterProtocolHandlerRef registerProtocolHandlerRef, const WKRegisterProtocolHandlerProvider* provider);

I don't think it is very common to have the primary name of an API start with a verb. I think a better fitting name would be for example "ProtocolHandlerRegistry" and therefore WKSetProtocolHandlerRegistryProvider.

> Source/WebKit2/UIProcess/WebContext.cpp:149
> +    , m_registerProtocolHandlerProxy(WebRegisterProtocolHandlerProxy::create(this))

This is an example of why I think having a verb as the first word in the name sounds strange. m_registerProtocolHandlerProxy sounds more like a function name than a noun, hence my suggestion of for example
m_protocolHandlerRegistryProxy or maybe just simply m_customProtocolHandlerProxy.
Comment 24 Mikhail Pozdnyakov 2012-08-24 04:12:41 PDT
(In reply to comment #23)
> (From update of attachment 158093 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=158093&action=review
> I don't think it is very common to have the primary name of an API start with a verb. I think a better fitting name would be for example "ProtocolHandlerRegistry" and therefore WKSetProtocolHandlerRegistryProvider.
> 
> > Source/WebKit2/UIProcess/WebContext.cpp:149
> > +    , m_registerProtocolHandlerProxy(WebRegisterProtocolHandlerProxy::create(this))
> 
> This is an example of why I think having a verb as the first word in the name sounds strange. m_registerProtocolHandlerProxy sounds more like a function name than a noun, hence my suggestion of for example
> m_protocolHandlerRegistryProxy or maybe just simply m_customProtocolHandlerProxy.

As I mentioned in the comment #18 such naming is already in WebKit, so have to be consistent. However I absolutely agree that the API should be renamed according to specs (http://www.w3.org/TR/html5/system-state-and-capabilities.html#custom-handlers), filed a separate bug for it 
https://bugs.webkit.org/show_bug.cgi?id=94920. I do not think it should be a blocker for this bug, as this bug just creates WK2 IPC infrastructure on top of the existing API.
Comment 25 Mikhail Pozdnyakov 2012-08-27 02:36:42 PDT
Comment on attachment 158093 [details]
patch v4

Need rebasing after bug94920 landed.
Comment 26 Mikhail Pozdnyakov 2012-08-27 03:34:44 PDT
Created attachment 160687 [details]
patch v5

Rebased.
Comment 27 Mikhail Pozdnyakov 2012-09-05 08:18:37 PDT
Here is a good description of how protocol handlers can be used and why they are needed:
https://developer.mozilla.org/en-US/docs/Web-based_protocol_handlers

protocol handler API is supported by Chromium and Firefox currently and I strongly believe that any WK2 client will benefit from it as well. 

Protocol handler should be applied to all the pages and that is why the proposed implementation is in WebContext.
Comment 28 Raphael Kubo da Costa (:rakuco) 2012-09-30 04:43:39 PDT
Anything left to get this in? Simon, Kenneth?
Comment 29 Sanghyun Park 2013-07-16 01:37:16 PDT
Is there any progress on this? 
If there is no progress, I want to follow up  this patch.
Comment 30 Sanghyun Park 2013-07-31 05:14:14 PDT
Created attachment 207839 [details]
Patch
Comment 31 Chris Dumez 2013-07-31 06:02:57 PDT
Comment on attachment 207839 [details]
Patch

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

> Source/WebKit2/ChangeLog:1
> +2013-07-31  Sanghyun Park  <sh919.park@samsung.com>

It is not acceptable not to mention the original author of the patch.

> Source/WebKit2/UIProcess/API/C/WKNavigatorContentUtils.cpp:2
> + * Copyright (C) 2013 Samsung Electronics. All rights reserved.

It is not acceptable either to strip / replace Intel's copyright as they wrote the initial patch.
Comment 32 Sanghyun Park 2013-07-31 06:35:53 PDT
(In reply to comment #31)
> (From update of attachment 207839 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=207839&action=review
> 
> > Source/WebKit2/ChangeLog:1
> > +2013-07-31  Sanghyun Park  <sh919.park@samsung.com>
> 
> It is not acceptable not to mention the original author of the patch.
> 
> > Source/WebKit2/UIProcess/API/C/WKNavigatorContentUtils.cpp:2
> > + * Copyright (C) 2013 Samsung Electronics. All rights reserved.
> 
> It is not acceptable either to strip / replace Intel's copyright as they wrote the initial patch.

Thank you for review.
I'll fix these.
Comment 33 Sanghyun Park 2013-07-31 08:38:19 PDT
Created attachment 207853 [details]
Patch
Comment 34 Gyuyoung Kim 2013-07-31 19:41:10 PDT
Comment on attachment 207853 [details]
Patch

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

> Source/WebKit2/ChangeLog:1
> +2013-07-31  Sanghyun Park  <sh919.park@samsung.com>

Or, you can add original author name as below,

Mikhail Pozdnyakov <mikhail.pozdnyakov@intel.com>, Sanghyun Park <sh919.park@samsung.com>
Comment 35 Sanghyun Park 2013-07-31 21:29:10 PDT
(In reply to comment #34)
> (From update of attachment 207853 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=207853&action=review
> 
> > Source/WebKit2/ChangeLog:1
> > +2013-07-31  Sanghyun Park  <sh919.park@samsung.com>
> 
> Or, you can add original author name as below,
> 
> Mikhail Pozdnyakov <mikhail.pozdnyakov@intel.com>, Sanghyun Park <sh919.park@samsung.com>

I will refer this, too. Thank you.
Comment 36 Gyuyoung Kim 2015-02-15 01:06:45 PST
Comment on attachment 207853 [details]
Patch

I think this patch should be rebased against latest trunk. Please update this patch. If you're not interested in this patch anymore, I would like to take over this patch.
Comment 37 Gyuyoung Kim 2015-05-11 01:01:23 PDT
Created attachment 252847 [details]
Patch
Comment 38 Gyuyoung Kim 2015-05-11 23:50:12 PDT
Created attachment 252943 [details]
Patch
Comment 39 WebKit Commit Bot 2015-05-11 23:51:35 PDT
Attachment 252943 [details] did not pass style-queue:


ERROR: Source/WebKit2/WebProcess/WebCoreSupport/WebNavigatorContentUtilsClient.h:34:  Do not use 'using namespace WebCore;'.  [build/using_namespace] [4]
Total errors found: 1 in 22 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 40 Gyuyoung Kim 2015-05-12 22:51:55 PDT
This feature has been supported by Chromium and Mozilla. So I would like to support this feature for WebKit as well. Could anyone take a look ?
Comment 41 Gyuyoung Kim 2015-05-13 23:31:12 PDT
CC'ing Darin, I wonder if you can take a look this patch.
Comment 42 Sam Weinig 2015-05-15 10:12:54 PDT
Support for navigator.registerProtocolHandler/unregisterProtocolHandler is not something we want to support in WebKit2 at this time as we are not confident it is a good Web API. This might be a good conversation for webkit-dev.
Comment 43 Gyuyoung Kim 2015-07-02 21:04:17 PDT
Created attachment 256069 [details]
Patch
Comment 44 WebKit Commit Bot 2015-07-02 21:07:13 PDT
Attachment 256069 [details] did not pass style-queue:


ERROR: Source/WebKit2/WebProcess/WebCoreSupport/WebNavigatorContentUtilsClient.h:34:  Do not use 'using namespace WebCore;'.  [build/using_namespace] [4]
Total errors found: 1 in 22 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 45 Gyuyoung Kim 2015-07-02 21:10:09 PDT
(In reply to comment #42)
> Support for navigator.registerProtocolHandler/unregisterProtocolHandler is
> not something we want to support in WebKit2 at this time as we are not
> confident it is a good Web API. This might be a good conversation for
> webkit-dev.

Though I headed up this API implementation on webkit-dev, I didn't get clear reason yet why we shouldn't support this feature now. Instead, some people wanted to support this feature.
Comment 46 Darin Adler 2015-07-04 09:38:44 PDT
I know you waited a long time and got no reply from Sam. But I still think we need to wait for Sam’s reply. Sam, is that right?
Comment 47 Sam Weinig 2015-07-04 10:27:08 PDT
(In reply to comment #46)
> I know you waited a long time and got no reply from Sam. But I still think
> we need to wait for Sam’s reply. Sam, is that right?

Mea culpa. I meant to respond a long time ago on this topic and had a draft sitting ready to go that I though I had sent.  I have now sent it to webkit-dev.
Comment 48 Gyuyoung Kim 2015-07-08 19:25:52 PDT
(In reply to comment #47)
> (In reply to comment #46)
> > I know you waited a long time and got no reply from Sam. But I still think
> > we need to wait for Sam’s reply. Sam, is that right?
> 
> Mea culpa. I meant to respond a long time ago on this topic and had a draft
> sitting ready to go that I though I had sent.  I have now sent it to
> webkit-dev.

As I replied on the thread, I think this feature won't complicate custom protocol. This just uses it.

https://lists.webkit.org/pipermail/webkit-dev/2015-July/027524.html


I plan to use this feature as below scenario. I would like to listen your opinion about it.

 1. Custom scheme is registered by "registeredProtocolHandler()" in JS
 2. The registered scheme will be filtering in WebCore. (If unsupported
scheme is requested, security error happens.)
 3. Filtered scheme will be passed to application side (of course, which is
web browser or similar things)
 4. The application will register the passed custom scheme and a callback(to
call the native embedding application) to WK2's network
     using "custom protocol handler feature", which was implemented in
WebKit2."
Comment 49 Gyuyoung Kim 2015-07-11 23:05:43 PDT
(In reply to comment #48)
> (In reply to comment #47)
> > (In reply to comment #46)
> > > I know you waited a long time and got no reply from Sam. But I still think
> > > we need to wait for Sam’s reply. Sam, is that right?
> > 
> > Mea culpa. I meant to respond a long time ago on this topic and had a draft
> > sitting ready to go that I though I had sent.  I have now sent it to
> > webkit-dev.
> 
> As I replied on the thread, I think this feature won't complicate custom
> protocol. This just uses it.
> 
> https://lists.webkit.org/pipermail/webkit-dev/2015-July/027524.html
> 
> 
> I plan to use this feature as below scenario. I would like to listen your
> opinion about it.
> 
>  1. Custom scheme is registered by "registeredProtocolHandler()" in JS
>  2. The registered scheme will be filtering in WebCore. (If unsupported
> scheme is requested, security error happens.)
>  3. Filtered scheme will be passed to application side (of course, which is
> web browser or similar things)
>  4. The application will register the passed custom scheme and a callback(to
> call the native embedding application) to WK2's network
>      using "custom protocol handler feature", which was implemented in
> WebKit2."

Sam, any comment ?
Comment 50 Gyuyoung Kim 2015-07-21 17:37:50 PDT
(In reply to comment #48)

> I plan to use this feature as below scenario. I would like to listen your
> opinion about it.
> 
>  1. Custom scheme is registered by "registeredProtocolHandler()" in JS
>  2. The registered scheme will be filtering in WebCore. (If unsupported
> scheme is requested, security error happens.)
>  3. Filtered scheme will be passed to application side (of course, which is
> web browser or similar things)
>  4. The application will register the passed custom scheme and a callback(to
> call the native embedding application) to WK2's network
>      using "custom protocol handler feature", which was implemented in
> WebKit2."

Sam, I spent 2 months to talk about this feature though, I'm still waiting for your reply. I think this scenario won't generate your concern. Could you please give me any your comment against my suggestion ?
Comment 51 Gyuyoung Kim 2015-08-05 21:50:09 PDT
Created attachment 258348 [details]
Patch
Comment 52 Brady Eidson 2017-04-24 19:10:24 PDT
Comment on attachment 258348 [details]
Patch

This patch has been pending review since 2015 with no recent activity.
It seems unlikely that it would even still apply to trunk in its current form.

Clearing from the review queue.

Feel free to update and resubmit if the patch is still relevant.

(Additional editorial note: We probably shouldn't bother enhancing the C-API anymore)