Rejecting on PaymentResponse.complete()
Reported by
mcace...@mozilla.com,
Aug 17 2017
|
||||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3187.0 Safari/537.36
Steps to reproduce the problem:
1. Navigate to a "secure context" (e.g., localhost or whatever).
2. paste attached code into dev console.
3. Hit pay, enter CVV.
4. Hit "Close".
5. See developer console ("DOMException: Request cancelled").
What is the expected behavior?
To not reject the resulting promise... it causes issues with async/await, because it will show up as an unhandled rejection.
What went wrong?
It rejected the promise when the use hit "Close".
Did this work before? N/A
Does this work in other browsers? N/A
Chrome version: 62.0.3187.0 Channel: canary
OS Version: OS X 10.12.6
Flash Version:
This is for conformance with Payment Request API spec.
,
Aug 17 2017
,
Aug 18 2017
,
Aug 21 2017
Thank you for the report! Will fix.
,
Sep 20 2017
Marcos, can you explain a bit more of what's wrong in Chrome's behavior? It appears that you got the promise returned by PaymentResponse.complete() to reject, but it's not clear what the user did to achieve this. Thank you!
,
Sep 21 2017
Sorry, this is a more reduced test case:
```
const methods = [{ supportedMethods: ["basic-card"] }];
const details = {
total: {
label: "Total due",
amount: { currency: "USD", value: "65.00" },
},
};
async function doPaymentRequest() {
const payResponse = await new PaymentRequest(methods, details).show();
await payResponse.complete("fail");
}
doPaymentRequest();
```
So, now, to reproduce:
1. paste code,
2. hit "Pay" button.
3. Enter CVV, hit "confirm".
4. Hit "Close".
> but it's not clear what the user did to achieve this.
Hitting the "close" causes the promise to reject. That shouldn't happen per spec. Hitting "close" should resolve with undefined and not reject.
,
Sep 22 2017
Should PaymentResponse.complete() promise ever reject in any circumstance?
,
Sep 22 2017
Yes. If called twice or more, for instance: https://www.w3.org/TR/payment-request/#complete()-method But hitting esc or hitting close on the UI shouldn’t cause a rejection after complete() is called. Let me know if this is not clear from the spec.
,
Sep 26 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/92296b66078c265fd8af1b56455e9c3fc6fcd800 commit 92296b66078c265fd8af1b56455e9c3fc6fcd800 Author: Rouslan Solomakhin <rouslan@chromium.org> Date: Tue Sep 26 19:46:03 2017 [Payments] Do not reject PaymentResponse.complete() promise Before this patch, when the user closes the PaymentRequest error message that states "Transaction failed, please try again," PaymentResponse.complete() promise would be rejected. This is contrary to the spec, which says the PaymentResponse.complete() promise should be resolved when the user closes the UI. Spec: https://www.w3.org/TR/payment-request/#complete()-method This patch changes the behavior of closing browser to resolve the PaymentResponse.complete() promise instead. After this patch, when the user closes the PaymentRequest error message that states "Transaction failed, please try again," PaymentResponse.complete() promise is resolved with undefined. Bug: 756298 Test: CompleteTest.ResolveCompletePromiseOnUnknownError Test: CompleteTest.ResolveCompletePromiseOnUserClosingUI Test: https://w3c-test.org/payment-request/payment-response/complete-method-manual.https.html Change-Id: If21b4b1c459432acf6f3156ddf26304f04f87918 Reviewed-on: https://chromium-review.googlesource.com/682794 Commit-Queue: Rouslan Solomakhin <rouslan@chromium.org> Reviewed-by: Mathieu Perreault <mathp@chromium.org> Cr-Commit-Position: refs/heads/master@{#504463} [modify] https://crrev.com/92296b66078c265fd8af1b56455e9c3fc6fcd800/third_party/WebKit/Source/modules/payments/CompleteTest.cpp [modify] https://crrev.com/92296b66078c265fd8af1b56455e9c3fc6fcd800/third_party/WebKit/Source/modules/payments/PaymentRequest.cpp
,
Sep 26 2017
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by mcace...@mozilla.com
, Aug 17 2017