Change what canMakePayment() means #806
Conversation
During the F2F, we came to a consensus that "canMakePayment" means "the user agent supports the PMIs" - but it does not mean that there is a payment instrument set up. We concluded that we might add something to check if there is an active instrument in the future.
|
Redid the test and updated MDN. |
|
How far in the future are we thinking about the active instrument check? |
|
I’m unsure - that was really unclear to me. Do we want it now? Can we live without it for V1? |
|
I would prefer to implement it soon, but don't want to force the other implementers or block the CR process. |
|
I guess we could at least draft it up and put everything in place, then check implementation plans. |
|
Good idea 👍 |
|
We couldn’t implement in Firefox for at least 3 month. We have a big backlog to finish just with the current stuff. That means 6 months till we would have something in release. |
|
Unrelated but, Mozilla folks put together this great wiki page that shows our implementation priorities, with explanations, and stuff we still need to do (@ianbjacobs and Chairs, you might like it): https://wiki.mozilla.org/Firefox/Features/Web_Payments/DOM It gives a good sense of where we are at and updates dynamically as we fix things, so good to periodically check. |
…ment method data https://bugs.webkit.org/show_bug.cgi?id=191432 Reviewed by Dean Jackson. LayoutTests/imported/w3c: * web-platform-tests/payment-request/payment-request-canmakepayment-method.https-expected.txt: Added. Source/WebCore: In w3c/payment-request#806, we're changing the specification of canMakePayment() to not consider serialized payment method data when deciding if a payment method is supported. For Apple Pay, this means we resolve to true for "https://apple.com/apple-pay", even if an ApplePayRequest is omitted or is missing required fields. Added test cases to http/tests/paymentrequest/payment-request-canmakepayment-method.https.html and http/tests/paymentrequest/payment-request-show-method.https.html. * Modules/paymentrequest/PaymentRequest.cpp: (WebCore::PaymentRequest::canMakePayment): LayoutTests: * http/tests/paymentrequest/payment-request-canmakepayment-method.https-expected.txt: * http/tests/paymentrequest/payment-request-canmakepayment-method.https.html: Updated with changes from imported/w3c/web-platform-tests/payment-request/. Modified two tests to use user_activation_test() rather than test_driver.bless(). * http/tests/paymentrequest/payment-request-show-method.https-expected.txt: * http/tests/paymentrequest/payment-request-show-method.https.html: Now that canMakePayment does not convert payment method data, added a test that ensures show() rejects with a TypeError when Apple Pay's payment method data is invalid. * platform/ios-wk2/TestExpectations: Un-skipped payment-request-canmakepayment-method.https.html. * platform/mac-wk2/TestExpectations: Ditto. git-svn-id: http://svn.webkit.org/repository/webkit/trunk@238042 268f45cc-cd09-0410-ab3c-d52691b4dbfc
3 participants
During the F2F, we came to a consensus that "canMakePayment" means "the user agent supports the PMIs" - but it does not mean that there is a payment instrument set up. We concluded that we might add something to check if there is an active instrument in the future.
closes #800
The following tasks have been completed:
Implementation commitment:
Optional, Impact on Payment Handler spec?
@ianbjacobs and @rsolomakhin, probably some impact! ☄️