[prev in list] [next in list] [prev in thread] [next in thread]
List: webkit-dev
Subject: Re: [webkit-dev] Support "registerProtocolHandler" in WebKit2
From: Brady Eidson <beidson () apple ! com>
Date: 2015-07-06 16:56:45
Message-ID: 9E98B043-D60C-4157-B448-E76A5D6358AB () apple ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> On Jul 1, 2015, at 7:42 PM, Gyuyoung Kim <gyuyoung.kim@webkit.org> wrote:
>
> WebKit2 already has a similar feature, which is so-called *custom protocol* enabled \
> by Mac, Gtk and EFL ports. However the custom protocol feature supports to register \
> custom scheme through API layer instead of JavaScript. The \
> registerProtocolHandler() is to support to register the custom scheme by means of \
> JavaScript. I don't know yet why we can't support to register it from JavaScript.
The custom protocol handler feature of the WebKit2 API is for the embedding native \
application to provide raw data to resource loads directly.
While tangentially related to how registerProtocolHandler would work for some uses, \
there's numerous differences.
One key example: Since it was implemented for the native embedding application (which \
is, of course, trusted) none of the normal web security concerns have been taken into \
account.
Also, since they're for special-use native apps instead of a general web browser, \
none of Sam's concerns had to be accounted for:
> On Jul 4, 2015, at 10:24 AM, Sam Weinig <weinig@apple.com> wrote:
>
> My concern with the registerProtocolHandler() API is that it complicates an already \
> the very complicated area of custom protocols and a good implementation requires \
> configuration UI (to choose which of potentially multiple apps/websites you want a \
> specific protocol to go to) that I am not sure users are in the \
> position make.
> ...
> From an implementation perspective I also have concerns. How is this should the \
> registration data be managed? Can it fit in the WebSiteData model we are using for \
> other data? Does it account for non-persistent sessions? And lastly, can we get \
> the code size of supporting a feature like this to be smaller?
I'm not crafting this reply as an argument against registerProtocolHandler, but \
rather to dispel the notion that exposing "WK2 custom protocols" to JS is all we need \
to do to get registerProtocolHandler.
~Brady
> Gyuyoung.
>
> On Tue, Jun 16, 2015 at 10:43 AM, Gyuyoung Kim <gyuyoung.kim@webkit.org \
> <mailto:gyuyoung.kim@webkit.org>> wrote: On Mon, Jun 8, 2015 at 9:39 AM, Darin \
> Adler <darin@apple.com <mailto:darin@apple.com>> wrote: Sam, Anders, you haven't \
> replied to the thread since Maciej made his remarks two weeks ago. He asked what \
> you dislike about the API.
> It seems that some people hope to listen why you guys dislike about this API as \
> well as I want.
> Gyuyoung.
>
> On Thu, Jun 11, 2015 at 10:06 AM, Gyuyoung Kim <gyuyoung.kim@webkit.org \
> <mailto:gyuyoung.kim@webkit.org>> wrote: On Mon, Jun 8, 2015 at 12:02 PM, Michael \
> Catanzaro <mcatanzaro@igalia.com <mailto:mcatanzaro@igalia.com>> wrote: On Sun, \
> 2015-06-07 at 17:39 -0700, Darin Adler wrote:
> > As one next step in the discussion, is there anyone that wants to
> > present a use case for a protocol other than mailto?
>
> irc:// would be useful for those who don't like desktop clients.
>
>
> "geo:" would be useful for people who want to use map application as well.
>
> Gyuyoung.
>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
[Attachment #5 (unknown)]
<html><head><meta http-equiv="Content-Type" content="text/html \
charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
-webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote \
type="cite" class=""><div class="">On Jul 1, 2015, at 7:42 PM, Gyuyoung Kim <<a \
href="mailto:gyuyoung.kim@webkit.org" class="">gyuyoung.kim@webkit.org</a>> \
wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" \
class="">WebKit2 already has a similar feature, which is so-called *custom protocol* \
enabled by Mac, Gtk and EFL ports. However the custom protocol feature supports to \
register custom scheme<div class="">through API layer instead of JavaScript. The \
registerProtocolHandler() is to support to register the custom scheme by means of \
JavaScript. I don't know yet why we can't support to register it</div><div \
class="">from JavaScript.</div></div></div></blockquote><br class=""></div><div>The \
custom protocol handler feature of the WebKit2 API is for the embedding native \
application to provide raw data to resource loads directly.</div><div><br \
class=""></div><div>While tangentially related to how registerProtocolHandler would \
work for some uses, there's numerous differences. </div><div><br \
class=""></div><div>One key example: Since it was implemented for the native \
embedding application (which is, of course, trusted) none of the normal web security \
concerns have been taken into account.</div><div><br class=""></div><div>Also, since \
they're for special-use native apps instead of a general web browser, none of Sam's \
concerns had to be accounted for:</div><div><br class=""></div><div><blockquote \
type="cite" class=""><div class="">On Jul 4, 2015, at 10:24 AM, Sam Weinig <<a \
href="mailto:weinig@apple.com" class="">weinig@apple.com</a>> wrote:</div><div \
class=""><br class="">My concern with the registerProtocolHandler() API is that it \
complicates an already the very complicated area of custom protocols and a good \
implementation requires configuration UI (to choose which of potentially multiple \
apps/websites you want a specific protocol to go to) that I am not sure users are in \
the position make. <br class="">...<br class="">From an implementation \
perspective I also have concerns. How is this should the registration data be \
managed? Can it fit in the WebSiteData model we are using for other data? Does it \
account for non-persistent sessions? And lastly, can we get the code size of \
supporting a feature like this to be smaller? <br \
class=""></div></blockquote><br class=""></div><div>I'm not crafting this reply as an \
argument against registerProtocolHandler, but rather to dispel the notion that \
exposing "WK2 custom protocols" to JS is all we need to do to get \
registerProtocolHandler.</div><div><br class=""></div><div>~Brady</div><div><br \
class=""></div><div><blockquote type="cite" class=""><div class=""><div dir="ltr" \
class=""><div class="">Gyuyoung.</div><div class="gmail_extra"><br class=""><div \
class="gmail_quote">On Tue, Jun 16, 2015 at 10:43 AM, Gyuyoung Kim <span dir="ltr" \
class=""><<a href="mailto:gyuyoung.kim@webkit.org" target="_blank" \
class="">gyuyoung.kim@webkit.org</a>></span> wrote:<br class=""><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div \
dir="ltr" class=""><span class="">On Mon, Jun 8, 2015 at 9:39 AM, Darin \
Adler <span dir="ltr" class=""><<a href="mailto:darin@apple.com" \
target="_blank" class="">darin@apple.com</a>></span> wrote:<br \
class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Sam, \
Anders, you haven't replied to the thread since Maciej made his remarks two weeks \
ago. He asked what you dislike about the API.</blockquote><div class=""><br \
class=""></div></span><div class="">It seems that some people hope to listen why you \
guys dislike about this API as well as I want.</div><span class=""><font \
color="#888888" class=""><div class=""><br class=""></div><div \
class="">Gyuyoung.</div></font></span></div><div class=""><div class=""><div \
class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Jun 11, 2015 at \
10:06 AM, Gyuyoung Kim <span dir="ltr" class=""><<a \
href="mailto:gyuyoung.kim@webkit.org" target="_blank" \
class="">gyuyoung.kim@webkit.org</a>></span> wrote:<br class=""><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div \
dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><span \
class="">On Mon, Jun 8, 2015 at 12:02 PM, Michael Catanzaro <span dir="ltr" \
class=""><<a href="mailto:mcatanzaro@igalia.com" target="_blank" \
class="">mcatanzaro@igalia.com</a>></span> wrote:<br class=""><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span \
class="">On Sun, 2015-06-07 at 17:39 -0700, Darin Adler wrote:<br class=""> > As \
one next step in the discussion, is there anyone that wants to<br class=""> > \
present a use case for a protocol other than mailto?<br class=""> <br class="">
</span>irc:// would be useful for those who don't like desktop clients.<br class="">
<div class=""><div class=""><br class=""></div></div></blockquote><div class=""><br \
class=""></div></span><div class="">"geo:" would be useful for people who want to use \
map application as well.</div><span class=""><font color="#888888" class=""><div \
class=""><br class=""></div><div class="">Gyuyoung.</div><div class=""><br \
class=""></div></font></span></div></div></div> </blockquote></div><br \
class=""></div> </div></div></blockquote></div><br class=""></div></div>
_______________________________________________<br class="">webkit-dev mailing \
list<br class=""><a href="mailto:webkit-dev@lists.webkit.org" \
class="">webkit-dev@lists.webkit.org</a><br \
class="">https://lists.webkit.org/mailman/listinfo/webkit-dev<br \
class=""></div></blockquote></div><br class=""></body></html>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic