- From: Marcos Cáceres <notifications@github.com>
- Date: Mon, 20 Mar 2017 06:01:11 -0700
- To: w3c/webpayments-payment-apps-api <webpayments-payment-apps-api@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/webpayments-payment-apps-api/pull/106/review/27498236@github.com>
marcoscaceres requested changes on this pull request.
> + Algorithm</a>.</p>
+ </section>
+ <section>
+ <h3><dfn>respondWith</dfn> method</h3>
+ <p>This method is used by the payment handler to provide
+ a <a>PaymentAppResponse</a> when the payment successfully
+ completes.</p>
+ </section>
+ <section>
+ <h3>Internal Slots</h3>
+ <p>Instances of <a>PaymentRequest</a> are created with
+ the internal slots in the following table:</p>
+ <table>
+ <tr>
+ <th>Internal Slot</th>
+ <th>Description (<em>non-normative</em>)</th>
If we are going to have defaults, we should have a default column in the table.
> + <th>Description (<em>non-normative</em>)</th>
+ </tr>
+ <tr>
+ <td><dfn>[[\windowClient]]</dfn></td>
+ <td>
+ The currently active <a>WindowClient</a>. This is
+ set if a payment handler is currently showing a
+ window to the user. Otherwise, it is null.
+ </td>
+ </tr>
+ </table>
+ </section>
+ <section>
+ <h3>Handling a payment request event</h3>
+ <p>Upon receiving a <a>payment request</a> by way of
+ <code>PaymentRequest.show()</code> and subsequent user
Nit: `<code><a data-cite="!payment-request#show-method">PaymentRequest.show()</a></code>`
> + <tr>
+ <td><dfn>[[\windowClient]]</dfn></td>
+ <td>
+ The currently active <a>WindowClient</a>. This is
+ set if a payment handler is currently showing a
+ window to the user. Otherwise, it is null.
+ </td>
+ </tr>
+ </table>
+ </section>
+ <section>
+ <h3>Handling a payment request event</h3>
+ <p>Upon receiving a <a>payment request</a> by way of
+ <code>PaymentRequest.show()</code> and subsequent user
+ selection of a payment handler, the <a>user agent</a>
+ MUST run the following steps or their equivalent:</p>
nit: remove "their equivalent"
> + The currently active <a>WindowClient</a>. This is
+ set if a payment handler is currently showing a
+ window to the user. Otherwise, it is null.
+ </td>
+ </tr>
+ </table>
+ </section>
+ <section>
+ <h3>Handling a payment request event</h3>
+ <p>Upon receiving a <a>payment request</a> by way of
+ <code>PaymentRequest.show()</code> and subsequent user
+ selection of a payment handler, the <a>user agent</a>
+ MUST run the following steps or their equivalent:</p>
+ <ol>
+ <li>Let <var>registration</var> be the <a>service
+ worker registration</a> corresponding to the payment
Expected link to "payment handler" definition
> - window in a new browser tab, as this is too dissociated from
- the checkout context.</p>
- <p>User agents SHOULD display the origin of a running payment
- handler to the user.</p>
+ <p>A payment handler that requires visual display and user
+ interaction, may call <a>openWindow()</a>. Since user agents
+ know that this method is connected to the payment request
+ event, they SHOULD render the window in a way that is
+ consistent with the flow and not confusing to the user.</p>
+ <p>The resulting window client is bound to the tab/window
+ that initiated the <a>payment request</a>. A single
+ <a>payment handler</a> SHOULD NOT be allowed to open more
+ than one client window using this method.</p>
+ <section>
+ <h3><dfn>Open Window Algorithm</dfn></h3>
+ <p class="note">This algorithm is <i>very</i> similar to
nit: class="ednote" ... should probably file a new bug for this, then we can link it to the spec.
> - window in a new browser tab, as this is too dissociated from
- the checkout context.</p>
- <p>User agents SHOULD display the origin of a running payment
- handler to the user.</p>
+ <p>A payment handler that requires visual display and user
+ interaction, may call <a>openWindow()</a>. Since user agents
+ know that this method is connected to the payment request
+ event, they SHOULD render the window in a way that is
+ consistent with the flow and not confusing to the user.</p>
+ <p>The resulting window client is bound to the tab/window
+ that initiated the <a>payment request</a>. A single
+ <a>payment handler</a> SHOULD NOT be allowed to open more
+ than one client window using this method.</p>
+ <section>
+ <h3><dfn>Open Window Algorithm</dfn></h3>
+ <p class="note">This algorithm is <i>very</i> similar to
See also: https://github.com/w3c/respec/wiki/Referencing-GitHub-issues-in-your-spec
> - <p>User agents SHOULD display the origin of a running payment
- handler to the user.</p>
+ <p>A payment handler that requires visual display and user
+ interaction, may call <a>openWindow()</a>. Since user agents
+ know that this method is connected to the payment request
+ event, they SHOULD render the window in a way that is
+ consistent with the flow and not confusing to the user.</p>
+ <p>The resulting window client is bound to the tab/window
+ that initiated the <a>payment request</a>. A single
+ <a>payment handler</a> SHOULD NOT be allowed to open more
+ than one client window using this method.</p>
+ <section>
+ <h3><dfn>Open Window Algorithm</dfn></h3>
+ <p class="note">This algorithm is <i>very</i> similar to
+ the <a href=
+ "https://www.w3.org/TR/service-workers/#clients-openwindow">
Nit: don't link to specs directly. instead:
```
<a data-cite="!service-workers/#clients-openwindow">Open Window Algorithm</a>
```
> - <p>User agents SHOULD display the origin of a running payment
- handler to the user.</p>
+ <p>A payment handler that requires visual display and user
+ interaction, may call <a>openWindow()</a>. Since user agents
+ know that this method is connected to the payment request
+ event, they SHOULD render the window in a way that is
+ consistent with the flow and not confusing to the user.</p>
+ <p>The resulting window client is bound to the tab/window
+ that initiated the <a>payment request</a>. A single
+ <a>payment handler</a> SHOULD NOT be allowed to open more
+ than one client window using this method.</p>
+ <section>
+ <h3><dfn>Open Window Algorithm</dfn></h3>
+ <p class="note">This algorithm is <i>very</i> similar to
+ the <a href=
+ "https://www.w3.org/TR/service-workers/#clients-openwindow">
And yes, we should do the security checks, and then defer to the the service worker algorithm.
> + <section>
+ <h3><dfn>Open Window Algorithm</dfn></h3>
+ <p class="note">This algorithm is <i>very</i> similar to
+ the <a href=
+ "https://www.w3.org/TR/service-workers/#clients-openwindow">
+ Open Window Algorithm</a> in the Service Workers
+ specification. Should we refer to the Service Workers
+ specification instead of copying their steps?</p>
+ <ol class="algorithm">
+ <li>Let <var>event</var> be this
+ <a>PaymentRequestEvent</a>.
+ </li>
+ <li>Let <var>request</var> be the <a>PaymentRequest</a>
+ that triggered this payment request event.
+ </li>
+ <li>If <var>request</var>.[[\state]] is not
nit: link to `<a>[[\state]]</a>`
> + <h3><dfn>Open Window Algorithm</dfn></h3>
+ <p class="note">This algorithm is <i>very</i> similar to
+ the <a href=
+ "https://www.w3.org/TR/service-workers/#clients-openwindow">
+ Open Window Algorithm</a> in the Service Workers
+ specification. Should we refer to the Service Workers
+ specification instead of copying their steps?</p>
+ <ol class="algorithm">
+ <li>Let <var>event</var> be this
+ <a>PaymentRequestEvent</a>.
+ </li>
+ <li>Let <var>request</var> be the <a>PaymentRequest</a>
+ that triggered this payment request event.
+ </li>
+ <li>If <var>request</var>.[[\state]] is not
+ "interactive", then return a Promise rejected with a <a>
Nit: link and define "interactive"
> + the <a href=
+ "https://www.w3.org/TR/service-workers/#clients-openwindow">
+ Open Window Algorithm</a> in the Service Workers
+ specification. Should we refer to the Service Workers
+ specification instead of copying their steps?</p>
+ <ol class="algorithm">
+ <li>Let <var>event</var> be this
+ <a>PaymentRequestEvent</a>.
+ </li>
+ <li>Let <var>request</var> be the <a>PaymentRequest</a>
+ that triggered this payment request event.
+ </li>
+ <li>If <var>request</var>.[[\state]] is not
+ "interactive", then return a Promise rejected with a <a>
+ DOMException</a> whose value is
+ "<a>InvalidStateError</a>".
Please see: https://www.w3.org/2001/tag/doc/promises-guide with regards to phrasing of these. It's close, but could be better.
> + Open Window Algorithm</a> in the Service Workers
+ specification. Should we refer to the Service Workers
+ specification instead of copying their steps?</p>
+ <ol class="algorithm">
+ <li>Let <var>event</var> be this
+ <a>PaymentRequestEvent</a>.
+ </li>
+ <li>Let <var>request</var> be the <a>PaymentRequest</a>
+ that triggered this payment request event.
+ </li>
+ <li>If <var>request</var>.[[\state]] is not
+ "interactive", then return a Promise rejected with a <a>
+ DOMException</a> whose value is
+ "<a>InvalidStateError</a>".
+ </li>
+ <li>Let <var>url</var> be the result of parsing the
Note, this can throw.
> + Open Window Algorithm</a> in the Service Workers
+ specification. Should we refer to the Service Workers
+ specification instead of copying their steps?</p>
+ <ol class="algorithm">
+ <li>Let <var>event</var> be this
+ <a>PaymentRequestEvent</a>.
+ </li>
+ <li>Let <var>request</var> be the <a>PaymentRequest</a>
+ that triggered this payment request event.
+ </li>
+ <li>If <var>request</var>.[[\state]] is not
+ "interactive", then return a Promise rejected with a <a>
+ DOMException</a> whose value is
+ "<a>InvalidStateError</a>".
+ </li>
+ <li>Let <var>url</var> be the result of parsing the
Also, we should invoke the [[!WHATWG-URL]] parser here.
> + <ol class="algorithm">
+ <li>Let <var>event</var> be this
+ <a>PaymentRequestEvent</a>.
+ </li>
+ <li>Let <var>request</var> be the <a>PaymentRequest</a>
+ that triggered this payment request event.
+ </li>
+ <li>If <var>request</var>.[[\state]] is not
+ "interactive", then return a Promise rejected with a <a>
+ DOMException</a> whose value is
+ "<a>InvalidStateError</a>".
+ </li>
+ <li>Let <var>url</var> be the result of parsing the
+ <var>url</var> argument.</li>
+ <li>If <var>url</var> is failure, return a Promise
+ rejected with a <a>TypeError</a>.
You should re-throw the error instead of creating an empty one.
> + <li>Let <var>url</var> be the result of parsing the
+ <var>url</var> argument.</li>
+ <li>If <var>url</var> is failure, return a Promise
+ rejected with a <a>TypeError</a>.
+ </li>
+ <li>If url is about:blank, return a Promise rejected with
+ a <a>TypeError</a>.
+ </li>
+ <li>Let <var>promise</var> be a new <a>Promise</a>.
+ </li>
+ <li>Run these steps in parallel:
+ <ol class="algorithm">
+ <li>Let <var>newContext</var> be a new <a>top level
+ browsing context</a>.
+ </li>
+ <li>Navigate <var>newContext</var> to <var>url</var>,
Nit: link to html navigate.
> + <li>Let <var>url</var> be the result of parsing the
+ <var>url</var> argument.</li>
+ <li>If <var>url</var> is failure, return a Promise
+ rejected with a <a>TypeError</a>.
+ </li>
+ <li>If url is about:blank, return a Promise rejected with
+ a <a>TypeError</a>.
+ </li>
+ <li>Let <var>promise</var> be a new <a>Promise</a>.
+ </li>
+ <li>Run these steps in parallel:
+ <ol class="algorithm">
+ <li>Let <var>newContext</var> be a new <a>top level
+ browsing context</a>.
+ </li>
+ <li>Navigate <var>newContext</var> to <var>url</var>,
Same with the exception types
> + <li>If <var>request</var>.[[\state]] is not
+ "interactive", then return a Promise rejected with a <a>
+ DOMException</a> whose value is
+ "<a>InvalidStateError</a>".
+ </li>
+ <li>Let <var>url</var> be the result of parsing the
+ <var>url</var> argument.</li>
+ <li>If <var>url</var> is failure, return a Promise
+ rejected with a <a>TypeError</a>.
+ </li>
+ <li>If url is about:blank, return a Promise rejected with
+ a <a>TypeError</a>.
+ </li>
+ <li>Let <var>promise</var> be a new <a>Promise</a>.
+ </li>
+ <li>Run these steps in parallel:
nit: link to in parallel
> + <li>If url is about:blank, return a Promise rejected with
+ a <a>TypeError</a>.
+ </li>
+ <li>Let <var>promise</var> be a new <a>Promise</a>.
+ </li>
+ <li>Run these steps in parallel:
+ <ol class="algorithm">
+ <li>Let <var>newContext</var> be a new <a>top level
+ browsing context</a>.
+ </li>
+ <li>Navigate <var>newContext</var> to <var>url</var>,
+ with exceptions enabled and replacement enabled.</li>
+ <li>If the navigation throws an exception, reject
+ <var>promise</var> with that exception and abort
+ these steps.</li>
+ <li>If the origin is not the same as the
Need to clear which origin (the origin of the newContext). Also, what happens if the newContext goes from:
```
newContext->foo.com REDIRECT newContext->bar.com REDIRECT newContext->foo.com
```
So probably need to track navigations.
> + </li>
+ <li>Run these steps in parallel:
+ <ol class="algorithm">
+ <li>Let <var>newContext</var> be a new <a>top level
+ browsing context</a>.
+ </li>
+ <li>Navigate <var>newContext</var> to <var>url</var>,
+ with exceptions enabled and replacement enabled.</li>
+ <li>If the navigation throws an exception, reject
+ <var>promise</var> with that exception and abort
+ these steps.</li>
+ <li>If the origin is not the same as the
+ <var>event</var>.<a>appRequest</a>.<a href=
+ "#dom-paymentapprequest-origin">origin</a>, then:
+ <ol class="algorithm">
+ <li>Resolve promise with null.</li>
Wonder why this doesn't reject with a SecurityError?
> + <li>If the navigation throws an exception, reject
+ <var>promise</var> with that exception and abort
+ these steps.</li>
+ <li>If the origin is not the same as the
+ <var>event</var>.<a>appRequest</a>.<a href=
+ "#dom-paymentapprequest-origin">origin</a>, then:
+ <ol class="algorithm">
+ <li>Resolve promise with null.</li>
+ <li>Abort these steps.</li>
+ </ol>
+ </li>
+ <li>Let <var>client</var> be the result of running
+ <a href=
+ "https://www.w3.org/TR/service-workers/#capture-windowclient-algorithm">
+ Capture Window Client</a> algorithm, or its
+ equivalent, with <var>newContext</var> as the
nit: drop "or its equivalent" (yes, I know it's in the SW spec... it's silly there too :))
> + "#dom-paymentapprequest-origin">origin</a>, then:
+ <ol class="algorithm">
+ <li>Resolve promise with null.</li>
+ <li>Abort these steps.</li>
+ </ol>
+ </li>
+ <li>Let <var>client</var> be the result of running
+ <a href=
+ "https://www.w3.org/TR/service-workers/#capture-windowclient-algorithm">
+ Capture Window Client</a> algorithm, or its
+ equivalent, with <var>newContext</var> as the
+ argument.
+ </li>
+ <li>If <var>event</var>.<a>[[\windowClient]]</a> is
+ not null, then:
+ <ol class="algorithm">
nit, I think you only need "algorithm" on the top-most `ol`
> + <li>Resolve promise with null.</li>
+ <li>Abort these steps.</li>
+ </ol>
+ </li>
+ <li>Let <var>client</var> be the result of running
+ <a href=
+ "https://www.w3.org/TR/service-workers/#capture-windowclient-algorithm">
+ Capture Window Client</a> algorithm, or its
+ equivalent, with <var>newContext</var> as the
+ argument.
+ </li>
+ <li>If <var>event</var>.<a>[[\windowClient]]</a> is
+ not null, then:
+ <ol class="algorithm">
+ <li>If
+ <var>event</var>.<a>[[\windowClient]]</a>.visibilityState
nit: link to .visibilityState, so one can see what other states it could possibly be in.
> @@ -843,70 +844,100 @@
[Exposed=ServiceWorker]
interface PaymentRequestEvent : ExtendableEvent {
readonly attribute PaymentAppRequest appRequest;
+ <a>Promise</a><<a>WindowClient</a>> openWindow(DOMString url);
This has to be a USVString. It can't be a DOMString. You can't pass a DOMString representing a URL.
> + </tr>
+ </table>
+ </section>
+ <section>
+ <h3>Handling a payment request event</h3>
+ <p>Upon receiving a <a>payment request</a> by way of
+ <code>PaymentRequest.show()</code> and subsequent user
+ selection of a payment handler, the <a>user agent</a>
+ MUST run the following steps or their equivalent:</p>
+ <ol>
+ <li>Let <var>registration</var> be the <a>service
+ worker registration</a> corresponding to the payment
+ handler selected by the user.
+ </li>
+ <li>If <var>registration</var> is not found, reject the
+ Promise that was created by
Nit: promise should be linked or treated as a concept. In either case, it should be linked to something.
> @@ -843,70 +844,100 @@
[Exposed=ServiceWorker]
interface PaymentRequestEvent : ExtendableEvent {
readonly attribute PaymentAppRequest appRequest;
+ <a>Promise</a><<a>WindowClient</a>> openWindow(DOMString url);
Don't add `a` elements inside IDL. ReSpec will do the linking for you.
> + <p>Upon receiving a <a>payment request</a> by way of
+ <code>PaymentRequest.show()</code> and subsequent user
+ selection of a payment handler, the <a>user agent</a>
+ MUST run the following steps or their equivalent:</p>
+ <ol>
+ <li>Let <var>registration</var> be the <a>service
+ worker registration</a> corresponding to the payment
+ handler selected by the user.
+ </li>
+ <li>If <var>registration</var> is not found, reject the
+ Promise that was created by
+ <code>PaymentRequest.show()</code> with a
+ <a>DOMException</a> whose value
+ "<a>InvalidStateError</a>" and terminate these steps.
+ </li>
+ <li>Invoke the <a>Handle Functional Event</a> algorithm
Nit: lowercase the algorithm name.
> + </table>
+ </section>
+ <section>
+ <h3>Handling a payment request event</h3>
+ <p>Upon receiving a <a>payment request</a> by way of
+ <code>PaymentRequest.show()</code> and subsequent user
+ selection of a payment handler, the <a>user agent</a>
+ MUST run the following steps or their equivalent:</p>
+ <ol>
+ <li>Let <var>registration</var> be the <a>service
+ worker registration</a> corresponding to the payment
+ handler selected by the user.
+ </li>
+ <li>If <var>registration</var> is not found, reject the
+ Promise that was created by
+ <code>PaymentRequest.show()</code> with a
We might want to abstract away ".show()", as in something can request request for payment, but not necessarily the Payment Request API.
> + <li>Let <var>registration</var> be the <a>service
+ worker registration</a> corresponding to the payment
+ handler selected by the user.
+ </li>
+ <li>If <var>registration</var> is not found, reject the
+ Promise that was created by
+ <code>PaymentRequest.show()</code> with a
+ <a>DOMException</a> whose value
+ "<a>InvalidStateError</a>" and terminate these steps.
+ </li>
+ <li>Invoke the <a>Handle Functional Event</a> algorithm
+ with a <a>service worker registration</a> of
+ <var>registration</var> and <var>callbackSteps</var>
+ set to the following steps:
+ <ol>
+ <li>Set <var>global</var> to the global object that
I'm confused, where was "global" passed?
> + handler selected by the user.
+ </li>
+ <li>If <var>registration</var> is not found, reject the
+ Promise that was created by
+ <code>PaymentRequest.show()</code> with a
+ <a>DOMException</a> whose value
+ "<a>InvalidStateError</a>" and terminate these steps.
+ </li>
+ <li>Invoke the <a>Handle Functional Event</a> algorithm
+ with a <a>service worker registration</a> of
+ <var>registration</var> and <var>callbackSteps</var>
+ set to the following steps:
+ <ol>
+ <li>Set <var>global</var> to the global object that
+ was provided as an argument.</li>
+ <li>Create a <a>trusted event</a>, <var>e</var>,
Use WHATWG-DOM fire an event here instead of the following subsets.
> + </li>
+ <li>Invoke the <a>Handle Functional Event</a> algorithm
+ with a <a>service worker registration</a> of
+ <var>registration</var> and <var>callbackSteps</var>
+ set to the following steps:
+ <ol>
+ <li>Set <var>global</var> to the global object that
+ was provided as an argument.</li>
+ <li>Create a <a>trusted event</a>, <var>e</var>,
+ that uses the
+ <code><a>PaymentRequestEvent</a></code> interface,
+ with the event type <code>paymentrequest</code>,
+ which does not bubble, cannot be canceled, and has
+ no default action.
+ </li>
+ <li>Set the <code>appRequest</code> attribute of
nit: `<code>` should be `<a>`
> @@ -927,16 +958,91 @@
configuration) performs its duties without opening a window
or requiring user interaction.</li>
</ul>
- <p class="issue">See <a href=
- "https://github.com/w3c/webpayments-payment-apps-api/issues/97">
- issue 97</a> for discussion about opening window in a way
- that is consistent with payment flow and not confusing to the
- user. For example, there is consensus that in a desktop
- environment, a payment handler should <em>not</em> open a
- window in a new browser tab, as this is too dissociated from
- the checkout context.</p>
- <p>User agents SHOULD display the origin of a running payment
- handler to the user.</p>
+ <p>A payment handler that requires visual display and user
Wait? who is the payment handler here? User code or the browser arbitrarily calling some JS function?
> @@ -927,16 +958,91 @@
configuration) performs its duties without opening a window
or requiring user interaction.</li>
</ul>
- <p class="issue">See <a href=
- "https://github.com/w3c/webpayments-payment-apps-api/issues/97">
- issue 97</a> for discussion about opening window in a way
- that is consistent with payment flow and not confusing to the
- user. For example, there is consensus that in a desktop
- environment, a payment handler should <em>not</em> open a
- window in a new browser tab, as this is too dissociated from
- the checkout context.</p>
- <p>User agents SHOULD display the origin of a running payment
- handler to the user.</p>
+ <p>A payment handler that requires visual display and user
+ interaction, may call <a>openWindow()</a>. Since user agents
+ know that this method is connected to the payment request
+ event, they SHOULD render the window in a way that is
+ consistent with the flow and not confusing to the user.</p>
This whole assertion seems very wishy-washy, tbh. Maybe this should be a note?
> - <p class="issue">See <a href=
- "https://github.com/w3c/webpayments-payment-apps-api/issues/97">
- issue 97</a> for discussion about opening window in a way
- that is consistent with payment flow and not confusing to the
- user. For example, there is consensus that in a desktop
- environment, a payment handler should <em>not</em> open a
- window in a new browser tab, as this is too dissociated from
- the checkout context.</p>
- <p>User agents SHOULD display the origin of a running payment
- handler to the user.</p>
+ <p>A payment handler that requires visual display and user
+ interaction, may call <a>openWindow()</a>. Since user agents
+ know that this method is connected to the payment request
+ event, they SHOULD render the window in a way that is
+ consistent with the flow and not confusing to the user.</p>
+ <p>The resulting window client is bound to the tab/window
Same with this... all this reads very "non-normative".
> @@ -634,9 +634,10 @@
<a>paymentrequest event</a> with a Payment App Request, and
uses the subsequent Payment App Response to create a
PaymentReponse for [[!PAYMENT-REQUEST-API]].</p>
- <section id="sec-app-request">
- <h3>Payment App Request</h3>The <a>payment app request</a> is
- conveyed using the following dictionary:
+ <section data-dfn-for="PaymentAppRequest" data-link-for="PaymentAppRequest">
+ <h3>Payment App Request</h3>
+ <p>The <a>payment app request</a> is
this is redundant. Talk about `PaymentAppRequest` instead.
> - instance, populated as described in <a href=
- "#sec-app-request"></a>.
- </li>
- <li>Dispatch <var>e</var> to <var>global</var>.</li>
- <li>Wait for all of the promises in the <a>extend
- lifetime promises</a> of <var>e</var> to resolve.
- </li>
- <li>If the <a>payment handler</a> has not provided a
- <a>payment app response</a> as described in
+ <section>
+ <h3><dfn>appRequest</dfn> attribute</h3>
+ <p>This attribute contains the <a>payment app request</a>
+ associated with this <a>payment request</a>.</p>
+ </section>
+ <section>
+ <h3><dfn data-lt="openWindow()">openWindow</dfn>
nit: `<dfn>openWindow()</dfn>`
> - <li>Dispatch <var>e</var> to <var>global</var>.</li>
- <li>Wait for all of the promises in the <a>extend
- lifetime promises</a> of <var>e</var> to resolve.
- </li>
- <li>If the <a>payment handler</a> has not provided a
- <a>payment app response</a> as described in
+ <section>
+ <h3><dfn>appRequest</dfn> attribute</h3>
+ <p>This attribute contains the <a>payment app request</a>
+ associated with this <a>payment request</a>.</p>
+ </section>
+ <section>
+ <h3><dfn data-lt="openWindow()">openWindow</dfn>
+ method</h3>
+ <p>This method is used by the payment handler to show a
+ window to the user. It invokes the <a>Open Window
Maybe say: "When called, it runs the ..." in lower case.
> - <li>If the <a>payment handler</a> has not provided a
- <a>payment app response</a> as described in
+ <section>
+ <h3><dfn>appRequest</dfn> attribute</h3>
+ <p>This attribute contains the <a>payment app request</a>
+ associated with this <a>payment request</a>.</p>
+ </section>
+ <section>
+ <h3><dfn data-lt="openWindow()">openWindow</dfn>
+ method</h3>
+ <p>This method is used by the payment handler to show a
+ window to the user. It invokes the <a>Open Window
+ Algorithm</a>.</p>
+ </section>
+ <section>
+ <h3><dfn>respondWith</dfn> method</h3>
nit: missing "()"
--
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/webpayments-payment-apps-api/pull/106#pullrequestreview-27498236
Received on Monday, 20 March 2017 13:01:55 UTC