Re: [w3c/manifest] Add protocol handlers to the explainer and spec (#863)

@marcoscaceres requested changes on this pull request.

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>

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=].

I think we have a nice shorthand for this: 

```suggestion
              <li>If <var>protocol_handler</var>["url"] is not [=manifest/within
              scope=], [=iteration/continue=].
```

> +        <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>
+        <p>
+          The steps for <dfn>processing the <code>protocol_handlers</code>
+          member</dfn> are given by the following algorithm. The algorithm
+          takes a <a data-cite=
+          "WEBIDL#sequence-type">sequence</a>&lt;<a>ProtocolHandlerItem</a>&gt;
+          <var>protocol_handlers</var> and a <a>URL</a> <var>manifest
+          URL</var>. This algorithm returns a <a data-cite=
+          "WEBIDL#sequence-type">sequence</a>&lt;<a>ProtocolHandlerItem</a>&gt;.
+        </p>
+        <ol>
+          <li>Let <var>processedProtocolHandlers</var> be a new Array object

probably make this a set, and then you can later check for duplicates with [=list/contains=]. 

> +        note that the [[HTML]] API uses <code>scheme</code> where we use
+        <code>protocol</code> but the same restrictions apply.
+      </p>
+      <section data-dfn-for="ProtocolHandlerItem" data-link-for=
+      "ProtocolHandlerItem">
+        <h3>
+          <code>protocol</code> member
+        </h3>
+        <p>
+          The <dfn>protocol</dfn> member of a <a>ProtocolHandlerItem</a> is a
+          <a>string</a> that represents the protocol to be handled, such as
+          "mailto" or "web+auth".
+        </p>
+        <p>
+          The <a>protocol</a> member of a <a>ProtocolHandlerItem</a> is
+          equivalent to <code>registerProtocolHandler</code>'s

```suggestion
          equivalent to {{NavigatorContentUtils/registerProtocolHandler()}}'s
```

> +          <code>scheme</code> argument defined in [[HTML]], and is processed in
+          the same manner.

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_handlers</var> and a <a>URL</a> <var>manifest
+          URL</var>. This algorithm returns a <a data-cite=
+          "WEBIDL#sequence-type">sequence</a>&lt;<a>ProtocolHandlerItem</a>&gt;.
+        </p>
+        <ol>
+          <li>Let <var>processedProtocolHandlers</var> be a new Array object
+          created as if by the expression [].
+          </li>
+          <li>For each <var>protocol_handler</var> (<a>ProtocolHandlerItem</a>)
+          in the sequence:
+            <ol>
+              <li>If <var>protocol_handler</var>["protocol"] or
+              <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

It's best to create a new variable here to store the newly parsed URL. 

> +        </p>
+        <p>
+          The <a>protocol</a> member of a <a>ProtocolHandlerItem</a> is
+          equivalent to <code>registerProtocolHandler</code>'s
+          <code>scheme</code> argument defined in [[HTML]], and is processed in
+          the same manner.
+        </p>
+      </section>
+      <section data-dfn-for="ProtocolHandlerItem" data-link-for=
+      "ProtocolHandlerItem">
+        <h3>
+          <code>url</code> member
+        </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

Please use "manifest scope" here, otherwise it might get confusing as "application scope" is not a defined thing.

> +          the same manner.
+        </p>
+      </section>
+      <section data-dfn-for="ProtocolHandlerItem" data-link-for=
+      "ProtocolHandlerItem">
+        <h3>
+          <code>url</code> member
+        </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
+          application's scope</a> that opens when the associated protocol is
+          activated.
+        </p>
+        <p>
+          The <a>url</a> member of a <a>ProtocolHandlerItem</a> is equivalent

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. 

> +          The <a>url</a> member of a <a>ProtocolHandlerItem</a> is equivalent
+          to <code>registerProtocolHandler</code>'s <code>url</code> argument
+          defined in [[HTML]], and is processed in the same manner.
+        </p>
+      </section>
+      <section>
+        <h3>
+          <dfn>Handling a protocol launch</dfn>
+        </h3>
+        <p>
+          When a <a>ProtocolHandlerItem</a> <var>protocol_handler</var> having
+          <a>WebAppManifest</a> <var>manifest</var> is invoked, run the
+          following steps:
+        </p>
+        <ol>
+          <li>Let <var>url</var> be <var>protocol_handler.url</var>.

The algorithm should operate on the document's "processed manifest" instead.

> +          defined in [[HTML]], and is processed in the same manner.
+        </p>
+      </section>
+      <section>
+        <h3>
+          <dfn>Handling a protocol launch</dfn>
+        </h3>
+        <p>
+          When a <a>ProtocolHandlerItem</a> <var>protocol_handler</var> having
+          <a>WebAppManifest</a> <var>manifest</var> is invoked, run the
+          following steps:
+        </p>
+        <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

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 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/863#pullrequestreview-614951036