Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106)

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