- From: Jungkee Song <notifications@github.com>
- Date: Thu, 01 Jun 2017 04:35:45 -0700
- To: w3c/payment-handler <payment-handler@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/payment-handler/issues/163/305467889@github.com>
Thanks @romandev for bringing me here. I think we better reuse the clients API's openWindow() steps as much as possible. In order to do so, I can factor out the default steps to a separate algorithm that paymentRequestEvent.openWindow() can invoke with its customized hook. (See this example that we do for importScripts of HTML and service workers: https://html.spec.whatwg.org/#dom-workerglobalscope-importscripts and https://w3c.github.io/ServiceWorker/#importscripts.) For the custom part of the steps, checking the request.[[state]] seems reasonable and easy to place in the begining of the algorithm I guess. But checking event.[[windowClient]] seems a bit too much specialized to. Is checking event.[[windowClient]]'s state something inevitable? In the importScripts's case, it was rather natural as service worker's importScripts() inherited the default implementation of WorkerGlobalScope.importScripts(). In the case of PaymentRequestEvent though, it currently defines openWindow() onto the event. I'm not sure whether we better/can just check the calling context from clients.openWindow() and if it's a paymentRequestEvent just apply the custom conditions there without adding a new method in the first place. /cc @domenic, @annevk, @jakearchibald -- 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/163#issuecomment-305467889
Received on Thursday, 1 June 2017 11:36:18 UTC