- From: Marcos Cáceres <notifications@github.com>
- Date: Mon, 21 Aug 2017 21:07:32 -0700
- To: w3c/payment-request <payment-request@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/payment-request/issues/589@github.com>
The way the spec is currently written, the payment sheet of a browser can lock up waiting on `ev.updateWith()` to be called. What actually needs to happen is: 1. That the developer needs to cancel the event somehow and then call `ev.updateWith()` - maybe .updateWith() cancels the event automatically? (I like this, because it means existing apps can continue to work without devs needing to make any changes to their existing code! And browsers need only make a small change.) 1. the browser needs to check if the event was cancelled. If yes, wait for `.updateWith()`. If no, reuse the existing data (or present whatever data the user has changed - like a new address or shipping option). Payment sheets already do this when changing credit cards, email, phone number, for instance (where no event is fired at the page). So, Proposal: * Calling `updateWith()` sets the event's cancel flag. * In the sheet: * If the event was not cancelled, then just update reusing the existing data + whatever new data the user provide/changed. * Otherwise, wait for `.updateWith()`'s promise to settle. Pre-empting discussion: checking if an event listener/handler is set on the payment request would [violate the DOM spec](https://dom.spec.whatwg.org/#observing-event-listeners) (because it would be a side-effect). That would be very bad. -- 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-request/issues/589
Received on Tuesday, 22 August 2017 04:07:54 UTC