-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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
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! ☄️