Re: [w3c/payment-handler] Suggest changing a shape of openWindow() (#300)

@gogerald Thank you for your feedback. I left some comments.

>Not sure I understand how this solves the second problem. Opened window still needs to know when to call 'navigator.paymentHandler.provideResponse', right?

The key difference is:
The original API resolves a return promise when a new window is **created**. On the other hand, the new API will resolve a return promise when the opened window is **closed**.

For the original API, `openWindow()` resolves a return promise with `WindowClient` as soon as a new window is created. After that, there is no opportunity to notify that the opened window is closed because `openWindow()` is already done. So, `postMessage()` is a unique way to notify that. But it’s not easy to determine when `postMessage` should be called even if using `beforeunload` or `pagevisibilitychange` events.

For the new API, it is not until the opened window is closed that `openWindow()` will not resolve(or reject) a return promise with `PaymentHandlerResponse`.
- If the window is not closed, the return promise is still pending.
- If the window is closed after calling `navigator.paymentHandler.provideResponse()`, the return promise will be resolved with `PaymentHandlerResponse` passed to `provideResponse()`.
- If the window is closed without calling `provideResponse()`, the result promise is rejected with `DOMException` such as `AbortError`.

>For the third problem, could we let opened window to contact SW to get payment request data every time after refresh ('load') so as not to cache payment request data?

Yes, we could but we aren't sure that `navigator.serviceWorker.controller` is always payment handlers SW. For example, if a payment handler site has two service workers as follows:
- XXX pay directory structures
```
/payment-handler/handler.js    // SW for payment handler
/payment-handler/register.html
/payment-handler/window/payment-ui.html
/payment-handler/window/cache-controller.js    // SW for UI Cache
```
The `handler.js` is a service worker for payment handler. Its scope is `/payment-handler/`. So, it can control `register.html` and `payment-ui.html`. BTW, for a performance reason, PaymentHandler author want to cache UI resources using some JS library(e.g. work box). So, the site also has a different service worker for UI resources caching.

In that case, The `navigator.servicwWorker.controller` in `payment-ui.html` will be `cache-controller.js` SW. Also, `navigator.servicwWorker.controller.postMessage()` in `payment-ui.html` will send the message to `cache-controller.js` SW.

Ideally, it would be better to combine the two SWs into a single SW but it's not easy to combine them that has each different purposes. I think it's unlikely that someone writes a general purpose SW util that can handle both cache and payment at the same time.

-- 
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/payment-handler/issues/300#issuecomment-385700316