Skip to content

Conversation

@stephenmcgruer
Copy link
Collaborator

@stephenmcgruer stephenmcgruer commented Nov 13, 2025

See #1040

The following tasks have been completed:

  • Modified Web platform tests (link)

Implementation commitment:

  • WebKit (link to issue)
  • Chromium (link to issue)
  • Gecko (link to issue)

Optional, impact on Payment Handler spec? <-- TBD!


Preview | Diff

@stephenmcgruer stephenmcgruer force-pushed the smcgruer-add-payment-handler-error-case branch from ccb85c9 to aaa261e Compare January 30, 2026 17:38
Copy link
Collaborator Author

@stephenmcgruer stephenmcgruer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I've incorporated your comments (thanks!) and put together three variants:

  1. A version where we take the unspecified error from the platform handler, and use the "let |error| be an appropriate {{DOMException}}" wording -e9eec11
  2. A version where the payment handler is presumed to pass us a DOMException directly (i.e., any conversion to DOMException happens 'inside' the relevant payment handler and any spec it has) - ae1280b
  3. A version which uses a general JavaScript value like AbortSignal does, and rejects with that reason - d976730

I personally prefer (2), but I'm open to any of them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants