← back to v149 · allow-payment-handlers-to-report-back-internal-errors
conformance · v149
v149 · allow-payment-handlers-to-report-back-internal-errors — conformance probe
7 assertions drawn from the spec. Each is a single contract the spec text makes. Pass/fail reflects what this browser executed; blocked means the contract was not run because it needs user mediation, hardware, or another unavailable precondition. Open the page in Chrome stable / canary / Firefox / Safari to compare.
0
pass
0
fail
0
blocked
7
total
| id | contract | kind | verdict | detail |
|---|---|---|---|---|
payment-request-constructor-exists |
PaymentRequest is exposed on the window as a constructable interface. spec ↗ | exists | … | |
payment-request-show-is-function |
PaymentRequest.prototype.show returns a Promise and is callable. spec ↗ | typeof | … | |
dom-exception-constructor-exists |
DOMException is constructable so handlers can throw AbortError vs OperationError. spec ↗ | exists | … | |
abort-error-name-round-trips |
A DOMException constructed with name 'AbortError' preserves the name (user-cancel signal). spec ↗ | script | … | |
operation-error-name-round-trips |
A DOMException constructed with name 'OperationError' preserves the name (internal-error signal). spec ↗ | script | … | |
payment-request-event-respond-with |
PaymentRequestEvent in a payment-handler service worker exposes respondWith for returning errors. spec ↗ | script | … | |
service-worker-container-exists |
navigator.serviceWorker is present so a payment handler can be registered. spec ↗ | exists | … |