[webkit-dev] Add a set of new APIs for the Custom Scheme and Content Handler.
mjs at apple.com
Tue Nov 29 00:59:07 PST 2011
Looks like I was mistaken and misread the spec, so I withdraw this comment.
Do other browsers that implement the register functions also implement the related isRegistered and unregister functions?
On Nov 29, 2011, at 12:08 AM, Maciej Stachowiak wrote:
> On Nov 28, 2011, at 8:54 PM, DongWoo Im wrote:
>> Hi webkit-dev,
>> I would like to let you know that I'm planning to add a set of new APIs for the Custom Scheme and Content Handler.
>> ** Specification link : http://dev.w3.org/html5/spec/Overview.html#custom-handlers
>> ** Bugs
>> - Custom Scheme Handler : https://bugs.webkit.org/show_bug.cgi?id=73176
>> - Custom Content Handler : https://bugs.webkit.org/show_bug.cgi?id=73177
>> Originally, there just defined a kind of set functions, 'registerProtocolHandler' and 'registerContentHandler'.
>> In this patch (73176, 73177), two more APIs are added per each handler.
>> (1) an API if a specific URL has been registered or not: 'isProtocolHandlerRegistered' and 'isContentHandlerRegistered'.
>> (2) an API to remove a registered URL: 'unregisterProtocolHandler' and 'unregisterContentHandler'.
>> I would think these additional APIs could make the Custom Handler more useful.
>> Also, I would like to roll back in the implementation of 'registerContentHandler', which was rolled out earlier.
>> This API was landed in r50477, but it rolled out in r62834 because the implementation was not completed in any WebKit port.
>> I will implement this API in the EFL port to support the 'registerContentHandler'.
>> It would be appreciated if you let me know how we could roll back in the 'registerContentHandler'.
> I think you should propose these to the relevant standards group before adding them to WebKit (either WHATWG or HTML WG). They do not seem valuable enough to add as WebKit-only extensions. And other vendors may be against them, for example, on privacy grounds. So we should discuss with the standards group first.
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
More information about the webkit-dev