https://bugs.webkit.org/show_bug.cgi?id=182631
Reviewed by Mark Lam.
Source/WebCore:
PaymentRequest::canMakePayment() needs to parse each payment method's serialized data to
determine if it is a supported payment method. If parsing fails by raising an exception, we
intend to skip over that payment method and try the next one. If all payment method data
fail to parse, we resolve the returned promise with false. At no point do we intend to
propagate the parsing exception up to the calling script, however.
Even though we intend to swallow any exceptions from parsing, we failed to clear the
JavaScript VM's exception state. The next time WebCore tries to execute JavaScript, a
release assertion is raised due to seeing an unexpected exception in the VM.
Fix this by using a CatchScope in PaymentRequest::canMakePayment(), and calling
CatchScope::clearException() in the places we intend to swallow exceptions.
Added a test case to http/tests/paymentrequest/payment-request-canmakepayment-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:
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@228331
268f45cc-cd09-0410-ab3c-
d52691b4dbfc
+2018-02-09 Andy Estes <aestes@apple.com>
+
+ [Payment Request] Crash in PaymentRequest::canMakePayment() when Apple Pay payment method data is missing required fields
+ https://bugs.webkit.org/show_bug.cgi?id=182631
+
+ Reviewed by Mark Lam.
+
+ * http/tests/paymentrequest/payment-request-canmakepayment-method.https-expected.txt:
+ * http/tests/paymentrequest/payment-request-canmakepayment-method.https.html:
+
2018-02-09 Ryan Haddad <ryanhaddad@apple.com>
Update TestExpectations for fast/forms/textarea/textarea-state-restore.html
PASS If request.[[state]] is "interactive", then return a promise rejected with an "InvalidStateError" DOMException.
PASS If request.[[state]] is "closed", then return a promise rejected with an "InvalidStateError" DOMException.
PASS If payment method identifier and serialized parts are supported, resolve promise with true.
+PASS If a payment method identifier is supported but its serialized parts are not, resolve promise with false.
PASS If payment method identifier is unknown, resolve promise with false.
PASS Optionally, at the user agent's discretion, return a promise rejected with a "NotAllowedError" DOMException.
<script src="/resources/testharness.js"></script>
<script src="/resources/testharnessreport.js"></script>
<script>
- const applePay = Object.freeze({
+const applePay = Object.freeze({
supportedMethods: "https://apple.com/apple-pay",
data: {
version: 2,
countryCode: "US",
}
});
+const invalidApplePay = Object.freeze({
+ supportedMethods: "https://apple.com/apple-pay",
+ data: {
+ }
+});
const defaultMethods = Object.freeze([applePay]);
const defaultDetails = Object.freeze({
total: {
}, `If payment method identifier and serialized parts are supported, resolve promise with true.`);
promise_test(async t => {
+ const request = new PaymentRequest([invalidApplePay], defaultDetails);
+ assert_false(await request.canMakePayment(), "Apple Pay with invalid data should not be supported");
+}, `If a payment method identifier is supported but its serialized parts are not, resolve promise with false.`);
+
+promise_test(async t => {
const unsupportedMethods = [
"this-is-not-supported",
"https://not.supported",
+2018-02-09 Andy Estes <aestes@apple.com>
+
+ [Payment Request] Crash in PaymentRequest::canMakePayment() when Apple Pay payment method data is missing required fields
+ https://bugs.webkit.org/show_bug.cgi?id=182631
+
+ Reviewed by Mark Lam.
+
+ PaymentRequest::canMakePayment() needs to parse each payment method's serialized data to
+ determine if it is a supported payment method. If parsing fails by raising an exception, we
+ intend to skip over that payment method and try the next one. If all payment method data
+ fail to parse, we resolve the returned promise with false. At no point do we intend to
+ propagate the parsing exception up to the calling script, however.
+
+ Even though we intend to swallow any exceptions from parsing, we failed to clear the
+ JavaScript VM's exception state. The next time WebCore tries to execute JavaScript, a
+ release assertion is raised due to seeing an unexpected exception in the VM.
+
+ Fix this by using a CatchScope in PaymentRequest::canMakePayment(), and calling
+ CatchScope::clearException() in the places we intend to swallow exceptions.
+
+ Added a test case to http/tests/paymentrequest/payment-request-canmakepayment-method.https.html.
+
+ * Modules/paymentrequest/PaymentRequest.cpp:
+ (WebCore::PaymentRequest::canMakePayment):
+
2018-02-09 Zalan Bujtas <zalan@apple.com>
[RenderTreeBuilder] Move multicolumn descendant/sibling removal logic to RenderTreeBuilder
return;
}
+ auto scope = DECLARE_CATCH_SCOPE(document.execState()->vm());
for (auto& paymentMethod : m_serializedMethodData) {
auto data = parse(document, paymentMethod.serializedData);
- if (data.hasException())
+ ASSERT(!!scope.exception() == data.hasException());
+ if (data.hasException()) {
+ scope.clearException();
continue;
+ }
auto handler = PaymentHandler::create(document, *this, paymentMethod.identifier);
if (!handler)
continue;
auto exception = handler->convertData(data.releaseReturnValue());
- if (exception.hasException())
+ ASSERT(!!scope.exception() == exception.hasException());
+ if (exception.hasException()) {
+ scope.clearException();
continue;
+ }
handler->canMakePayment([promise = WTFMove(promise)](bool canMakePayment) mutable {
promise.resolve(canMakePayment);