- From: Marcos Cáceres <notifications@github.com>
- Date: Wed, 15 Mar 2017 01:39:05 -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/27014728@github.com>
marcoscaceres requested changes on this pull request. > @@ -889,6 +889,7 @@ [Exposed=ServiceWorker] interface PaymentRequestEvent : ExtendableEvent { readonly attribute PaymentAppRequest appRequest; + Promise<WindowClient> openWindow(DOMString url); URL are USVStrings > @@ -898,6 +899,11 @@ This attribute contains the <a>payment app request</a> associated with this <a>payment request</a>. </dd> + <dt><code>openWindow</code> method</dt> Please define methods in their own section. > @@ -898,6 +899,11 @@ This attribute contains the <a>payment app request</a> associated with this <a>payment request</a>. </dd> + <dt><code>openWindow</code> method</dt> + <dd> + This method is used by the payment handler to show a window to + the user. Should like to algorithm that describes steps > @@ -964,9 +970,15 @@ opens a window. For subsequent payments in the same session, the payment handler (through 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 <code>PaymentRequestEvent.openWindow()</code>. nit: `<code>PaymentRequestEvent.openWindow()</code>.` <a>openWindow()</a>`. > @@ -964,9 +970,15 @@ opens a window. For subsequent payments in the same session, the payment handler (through 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 <code>PaymentRequestEvent.openWindow()</code>. + 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. All this needs to be in algorithm. > @@ -964,9 +970,15 @@ opens a window. For subsequent payments in the same session, the payment handler (through 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 <code>PaymentRequestEvent.openWindow()</code>. + 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. + The exact behavior in the case where a payment handler calls <code>openWindow()</code> multiple times, is left to the user agent implementers to decide on. It should probably throw. > @@ -964,9 +970,15 @@ opens a window. For subsequent payments in the same session, the payment handler (through 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 <code>PaymentRequestEvent.openWindow()</code>. + 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. + The exact behavior in the case where a payment handler calls <code>openWindow()</code> multiple times, is left to the user agent implementers to decide on. (invalid state error) > @@ -964,9 +970,15 @@ opens a window. For subsequent payments in the same session, the payment handler (through 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 <code>PaymentRequestEvent.openWindow()</code>. + 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. + The exact behavior in the case where a payment handler calls <code>openWindow()</code> multiple times, is left to the user agent implementers to decide on. + User agents MAY, in this case, let subsequent calls to <code>openWindow()</code> resolve to the same <code>WindowClient</code> instance.</p> + + <p>User agents SHOULD display the origin of the payment handler to the user.</p> Should be in the privacy and security considerations section -- 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-27014728
Received on Wednesday, 15 March 2017 08:45:47 UTC