Add protocol handlers to the explainer and spec #863
Conversation
|
@mgiuca / @marcoscaceres / @aarongustafson this is a first stab at having |
|
@dmurph who registered concerns with the overlap with |
|
Thanks Daniel. There are at least a couple that can be moved forward with a PR against the explainer. I'll work on updating those. |
|
Converted this to a draft while @diekus works on the updates. |
|
Just a heads up that the spec no longer uses WebIDL and I've changed slightly how processing of members happen. I also got rid of "issue a developer warning", and left that up to UAs. |
There was a problem hiding this comment.
some issues, but a good base to build on! Thanks for putting this together @fabiorocha!
| <p class="note"> | ||
| Protocol handlers could, for instance, be used for web app | ||
| communication where one app directly invokes another and passes data | ||
| via custom protocol links. | ||
| </p> | ||
| <p> | ||
| How protocol handlers are presented, and how many of them are shown | ||
| to the user, is at the discretion of the user agent and/or operating | ||
| system. | ||
| </p> |
There was a problem hiding this comment.
This doesn't sound amazing from a security perspective. I'm assuming all cross app communication is user mediated?
| <li>If <var>protocol_handler</var>["url"] is not <a>within | ||
| scope</a> of <var>manifest URL</var>, <a>issue a developer | ||
| warning</a> and [=iteration/continue=]. |
There was a problem hiding this comment.
I think we have a nice shorthand for this:
| <li>If <var>protocol_handler</var>["url"] is not <a>within | |
| scope</a> of <var>manifest URL</var>, <a>issue a developer | |
| warning</a> and [=iteration/continue=]. | |
| <li>If <var>protocol_handler</var>["url"] is not [=manifest/within | |
| scope=], [=iteration/continue=]. |
| "WEBIDL#sequence-type">sequence</a><<a>ProtocolHandlerItem</a>>. | ||
| </p> | ||
| <ol> | ||
| <li>Let <var>processedProtocolHandlers</var> be a new Array object |
There was a problem hiding this comment.
probably make this a set, and then you can later check for duplicates with [=list/contains=].
| </p> | ||
| <p> | ||
| The <a>protocol</a> member of a <a>ProtocolHandlerItem</a> is | ||
| equivalent to <code>registerProtocolHandler</code>'s |
There was a problem hiding this comment.
| equivalent to <code>registerProtocolHandler</code>'s | |
| equivalent to {{NavigatorContentUtils/registerProtocolHandler()}}'s |
| <code>scheme</code> argument defined in [[HTML]], and is processed in | ||
| the same manner. |
There was a problem hiding this comment.
this is probably not sufficient... here we want to make sure the HTML folks export something out from there spec that we can call into to process these.
| <var>protocol_handler</var>["url"] are undefined, <a>issue a | ||
| developer warning</a> and [=iteration/continue=]. | ||
| </li> | ||
| <li>Set <var>protocol_handler</var>["url"] to the result of [=URL |
There was a problem hiding this comment.
It's best to create a new variable here to store the newly parsed URL.
| </h3> | ||
| <p> | ||
| The <dfn>url</dfn> member of a <a>ProtocolHandlerItem</a> is the | ||
| <a>URL</a> <a data-lt="within scope of a manifest">within the |
There was a problem hiding this comment.
Please use "manifest scope" here, otherwise it might get confusing as "application scope" is not a defined thing.
| activated. | ||
| </p> | ||
| <p> | ||
| The <a>url</a> member of a <a>ProtocolHandlerItem</a> is equivalent |
There was a problem hiding this comment.
as above... this is probably not ideal (as per the TAG comments about layering). We own our own definitions of these things, and then we make them work with the underlying model of HTML.
| following steps: | ||
| </p> | ||
| <ol> | ||
| <li>Let <var>url</var> be <var>protocol_handler.url</var>. |
There was a problem hiding this comment.
The algorithm should operate on the document's "processed manifest" instead.
| <ol> | ||
| <li>Let <var>url</var> be <var>protocol_handler.url</var>. | ||
| </li> | ||
| <li>Replace the first occurrence of the exact literal string "%s" in |
There was a problem hiding this comment.
Ok, this bit probably needs really precise processing as a simple replace here might end up with security issues. If anything, we want to do whatever HTML does ... or maybe whatever Web Share Target does.
cc @mgiuca
|
It looks like protocol handlers are already defined at the Manifest Incubations spec. So, I would go ahead and close this four-year-old draft PR. |
Closes #846
This change (choose one):
changes normative sections without changing behavior)
Implementation commitment (delete if not making normative changes):
Commit message:
Add protocol handlers to the explainer and spec.
Preview | Diff