Re: [w3c/payment-request] proposed addition: passing data on complete() (PR #982)

@marcoscaceres commented on this pull request.



> @@ -2084,6 +2116,40 @@ <h2>
           </li>
           <li>Set |response|.{{PaymentResponse/[[complete]]}} to true.
           </li>
+          <li class="addition proposed">Let |serializedData| be the result of
+          <a>JSON-serializing</a> |details|.{{PaymentCompleteDetails/data}}
+          into a string.
+          </li>
+          <li class="addition proposed">If serializing [=exception/throws=] an
+          exception, return <a>a promise rejected with</a> that exception.
+            <div class="issue">
+              What should happen if an exception is thrown here? Should we

Agree on point 1 (being able to recover). My worry was that an unhandled promise rejection would leave the payment sheet hanging open, but the browser can either auto-close it after some time or provide some other means for the user to close it. 

About point 2, we could add some thing state "processing" or whatever, but it might be best to hold off until there is a concrete situation where that might happen. In theory, doing the IDL conversion steps should catch any issues... oh! That reminds me, we should do `.data` validation at this point also (same as we did in https://github.com/w3c/payment-request/pull/976).  

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

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