Payments code does some probably-invalid things with exceptions
Categories
(Core :: DOM: Web Payments, defect, P3)
Tracking
()
People
(Reporter: bzbarsky, Unassigned)
Details
Consider the case when PaymentResponse::Retry
is called with something like this as the arg:
{ paymentMethod: { /* getters that return valid things the first time but throw the second time */ } }
What will happen? We will call PaymentResponse::ConvertPaymentMethodErrors
and that will succeed because the getters return valid things the first time. Then we will call PaymentRequest::RetryPayment
which will call PaymentRequestManager::RetryPayment
. This will try to SerializeFromJSObject
aErrors.mPaymentMethod.Value()
, which will throw an exception on the JSContext
, because the getters now throw. The stack will unwind back to PaymentResponse::Retry
with an error nsresult and an exception on the JSContext
. That code will then do:
promise->MaybeReject(rv);
which will fatally assert at https://searchfox.org/mozilla-central/rev/cfd1cc461f1efe0d66c2fdc17c024a203d5a2fd8/dom/script/ScriptSettings.cpp#374 in debug builds and in opt builds reject with an error that has nothing to do with the exception that was thrown.
What is the actual behavior we want here? Should the exceptions from the getters end up in the promise rejection? Or should there be some other thing there? In any case, we should make sure we clear the exception from the JSContext one way or another before calling MaybeReject
... And we should have tests exercising this stuff.
Updated•3 years ago
|
Updated•3 years ago
|
Description
•