Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 130b88c82e3c20a8f592763b085e7d4a08b1b79e
https://github.com/WebKit/WebKit/commit/130b88c82e3c20a8f592763b085e7d4a08b1b79e
Author: Abrar Rahman Protyasha <[email protected]>
Date: 2026-01-20 (Tue, 20 Jan 2026)
Changed paths:
M LayoutTests/http/tests/ssl/applepay/ApplePaySession-expected.txt
M LayoutTests/http/tests/ssl/applepay/ApplePaySession.html
M LayoutTests/http/tests/ssl/applepay/PaymentRequest.https-expected.txt
M LayoutTests/http/tests/ssl/applepay/PaymentRequest.https.html
M Source/WebCore/Modules/applepay/ApplePayRequestBase.cpp
M Source/WebCore/Modules/applepay/ApplePaySessionPaymentRequest.h
Log Message:
-----------
[ApplePay] Unrecognized payment networks need not always throw exceptions
https://bugs.webkit.org/show_bug.cgi?id=305793
rdar://163015780
Reviewed by Wenson Hsieh.
Apple Pay on the web flows can handle unrecognized payment networks more
gracefully. Currently, if the ApplePayPaymentRequest.supportedNetworks
array contains an unknown value, a TypeError is thrown and no payment
sheet is presented.
Historically, developers could key off of the Apple Pay API version
number to evaluate whether a given network would be recognized in the
current device. However, there is no longer a tight cadence between new
network support, OS version changes, and Apple Pay API version changes.
The current recommend technique is for developers to test the networks
and filter out unrecognised values, however this technique is cumbersome,
and requires developers to write lots of boilerplate code.
In this patch, we migrate this filtering approach in to WebKit,
abstracting away this need from page authors. Concretely, we no longer
immediately throw a TypeError when we encounter a network value that is
not recognized by the platform. Instead, we now produce console warnings
in these situations and pare down the provided supportedNetworks array
to only recognized values. We only throw an exception if this array is
empty.
Gracefully handling these unrecognized networks yields the following
benefits:
- Simpler merchant integrations: developers need not write convoluted
boilerplate evluation code to create a payment request.
- Smoother Apple Pay user experience: reduces the frequency with which
payment sheets are unexpectedly not presented.
- Simpler documentation: this takes page authors one step closer to not
requiring use of the Apple Pay API version number, and we can now drop
this from the supportedNetworks array documentation, c.f.
https://developer.apple.com/documentation/applepayontheweb/applepaypaymentrequest/supportednetworks.
No new tests, however, some existing tests have been rebaselined
because of the behavior change with exceptions thrown.
* LayoutTests/http/tests/ssl/applepay/ApplePaySession-expected.txt:
* LayoutTests/http/tests/ssl/applepay/ApplePaySession.html:
* LayoutTests/http/tests/ssl/applepay/PaymentRequest.https-expected.txt:
* LayoutTests/http/tests/ssl/applepay/PaymentRequest.https.html:
* Source/WebCore/Modules/applepay/ApplePayRequestBase.cpp:
(WebCore::convertAndValidate):
* Source/WebCore/Modules/applepay/ApplePaySessionPaymentRequest.h:
(WebCore::ApplePaySessionPaymentRequest::setSupportedNetworks):
Drive-by fix: The only caller now moves a vector of strings, so teach
move semantics to this setter.
Canonical link: https://commits.webkit.org/305895@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
