Improve error codes

[rsolomakhin]

Four separate categories of error states return AbortError with vendor-specific error messages. Each of these categories requires a separate response from the merchant.

1. User closed the UI intentionally, .e.g, by clicking on the "Cancel Payment" button. Merchant may want to count this against their completion rate metrics. The user should remain on the checkout page.
2. User closed the UI, but it may have been unintentional. For example, switching tabs on Android will close the UI, although cancelling payment may not have been user's intention. Merchants may want to not count this against their completion rate metrics. The user should remain on the checkout page.
3. The browser UI or the payment app failed to launch. For example, the payment handler threw an exception when beginning to handle the paymentrequest event. Merchants may want to provide a fallback checkout experience, e.g., autofill form fields for credit card input. Merchants may want to let the payment app provider know about a bug in their code.
4. The browser UI or the payment app launched and user interacted with it, but the payment app failed to return a valid result, e.g., payment app did not specify any data in their response. Merchants may want to let the payment app provider know about a bug in their code. I'm not sure what kind of mitigation is the most appropriate in this case.

Chrome returns different message strings with these categories of messages, but requiring the merchant to distinguish errors by message strings is brittle and flaky. I propose that PR 1.1+ should standardize some error codes that the browser should return when rejecting PaymentRequest.show(). For example:

1. Error code 1 for intentional UI closing.
2. Error code 2 for unintentional UI closing.
3. Error code 3 for failure to launch a payment flow.
4. Error code 4 for failure during payment flow.

Error messages themselves can remain vendor specific, as long as they follow the format:

Error <X>: <Vendor-specific message here>

[rsolomakhin]

Suggestion originally from @noncombatant

[marcoscaceres]

We've generally moved away from error codes like the above in the web platform... "Legacy code name and value" where there are now gaps: https://heycam.github.io/webidl/#idl-DOMException-error-names

We generally don't want to distinguish too much between how browsers behave and exposing user actions.... like, the tab switching behavior where the payment sheet closes might be Chrome specific behavior, but not necessarily something another browser does (e.g., I might switch to my bank's site to check if I have enough money in my bank account before I make a purchase... on Firefox, I would expect the payment sheet to still be there and the site not to know that I'm doing something else).

Having said that, we could review the errors we are throwing and see if we can be more specific... distinguishing between developer error and user (agent) aborts would be good, but I would caution going beyond that.

[rsolomakhin]

@marcoscaceres : If we want to use existing DOMException error names, then error cases 3 and 4 could reject show() with OperationError instead of AbortError. WDYT?

[marcoscaceres]

I think that would be ok... alternatively, we throw just a general TypeError, which I think it's more common nowadays for data errors.

Might be worth throwing up a PR with the proposed changes and where you think we should change.

[marcoscaceres]

@rsolomakhin, should we still do this?

[rsolomakhin]

Let's put this in the ice box and possibly re-open in the future if the need arises.