Open Bug 1610876 Opened 3 years ago Updated 3 years ago

Payments code does some probably-invalid things with exceptions


(Core :: DOM: Web Payments, defect, P3)





(Reporter: bzbarsky, Unassigned)


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:


which will fatally assert at 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.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.