Re: [w3c/payment-request] Allow payment handlers to report back errors via Payment Request API (PR #1050)

@stephenmcgruer commented on this pull request.

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 -https://github.com/w3c/payment-request/pull/1050/changes/e9eec11036ebd2fcc0bbfd3a7c28cf958b1848ee
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) - https://github.com/w3c/payment-request/pull/1050/changes/ae1280b092e7f2c0781ac539d80ba6f75c0e60b9
3. A version which uses a general JavaScript value [like AbortSignal does](https://dom.spec.whatwg.org/#abortsignal-abort-reason), and rejects with that reason - https://github.com/w3c/payment-request/pull/1050/changes/d9767303206ed7dca116564ea3e9aca74d54d334

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

> @@ -1317,10 +1317,11 @@ <h2>
               </p>
             </aside>
             <p>
-              The |acceptPromise| will later be resolved or rejected by either
-              the <a>user accepts the payment request algorithm</a> or the
-              <a>user aborts the payment request algorithm</a>, which are
-              triggered through interaction with the user interface.
+              The |acceptPromise| will later be resolved or rejected by
+              the <a>user accepts the payment request algorithm</a>, the

Done.

> @@ -2599,9 +2600,10 @@ <h2>
           <li>Return |retryPromise|.
             <p class="note">
               The |retryPromise| will later be resolved by the <a>user accepts
-              the payment request algorithm</a>, or rejected by either the
-              <a>user aborts the payment request algorithm</a> or <a>abort the
-              update</a>.
+              the payment request algorithm</a>, or rejected by the <a>user
+              aborts the payment request algorithm</a>, <a>abort the update</a>,

Done.

> +        </p>
+        <ol class="algorithm">
+          <li>Let |request:PaymentRequest| be the {{PaymentRequest}} object
+          that the user is interacting with.
+          </li>
+          <li>If |request|.{{PaymentRequest/[[state]]}} is not
+          "[=PaymentRequest/interactive=]", then terminate this algorithm and
+          take no further action.
+          </li>
+          <li>Set |request|.{{PaymentRequest/[[state]]}} to
+          "[=PaymentRequest/closed=]".
+          </li>
+          <li>Set |request|'s <a>payment-relevant browsing context</a>'s
+          <a>payment request is showing</a> boolean to false.
+          </li>
+          <li>Let |error| be an {{"OperationError"}} {{DOMException}}.

No longer applicable; we now throw the `reason`.

> @@ -3946,6 +3948,56 @@ <h2>
           </li>
         </ol>
       </section>
+      <section>
+        <h2>
+          Payment handler indicates an internal error algorithm
+        </h2>
+        <p>
+   The <dfn>payment handler indicates an internal error algorithm</dfn>
+          runs when the payment handler that the user has selected reports an
+          internal error to the user agent. It MUST <a>queue a task</a> on the

Moved to step 1.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-request/pull/1050#pullrequestreview-3729594117
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/payment-request/pull/1050/review/3729594117@github.com>