Re: [w3c/webpayments-payment-apps-api] Different approaches to opening windows (#97)

> albeit with a need to specify that the web browser make the determination that such a window is being opened in a web payment context and takes steps to render it sensible

Unfortunately this is towards impossible. In an asynchronous execution environment like JavaScript you can't really link a call to `openWindow` with a "payment" event unless it's done synchronously. This is one of the reasons we have `event.waitUntil` on all service worker events, rather than a single global `waitUntil`.

> With PaymentRequestEvent.openClientWindow(), the fact that this is a different kind of window altogether is clearer, and the binding between the window and its corresponding event is also clearer. On the downside, this approach requires us to respecify a substantial amount of existing handling

I think you'd have that problem anyway, since you're wanting to display the client in a particular way, different to how `openWindow` usually works.

I'm open to refactoring the service worker spec to make these parts more reusable.

>From the email I sent to the list:

This still relies on `postMessage` to communicate with the client. I'm in two minds about it, but there may be higher-level options that would allow the client to produce the response itself. Eg:

```js
addEventListener("paymentrequest", event => {
  if (canHandleWithoutUi) {
    event.respondWith(response);
    return;
  }
  event.respondWith(event.showWindow(url));
});
```

And the window would have something like navigator.payments.provideResponse(response) which, when called, would close the window, and pass the result back to the service worker. Again, I'm in two minds about it, but it'd remove the need for the clunky `postMessage` work.

-- 
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/issues/97#issuecomment-274787159