|
499 | 499 | [Constructor(sequence<PaymentMethodData> methodData, PaymentDetailsInit details, optional PaymentOptions options),
|
500 | 500 | SecureContext, Exposed=Window]
|
501 | 501 | interface PaymentRequest : EventTarget {
|
502 |
| - Promise<PaymentResponse> show(); |
| 502 | + Promise<PaymentResponse> show(optional Promise<PaymentDetailsUpdate> detailsPromise); |
503 | 503 | Promise<void> abort();
|
504 | 504 | Promise<boolean> canMakePayment();
|
505 | 505 |
|
|
824 | 824 | p>
|
825 | 825 | div>
|
826 | 826 | <p data-tests="payment-request-show-method.https.html">
|
827 |
| - The <a>show()a> method MUST act as follows: |
| 827 | + The <code><a data-lt="show()">show(detailsPromise)a>code> method |
| 828 | + MUST act as follows: |
828 | 829 | p>
|
829 | 830 | <ol class="algorithm">
|
830 | 831 | <li>Let <var>requestvar> be the <a>PaymentRequesta> object on
|
|
937 | 938 | <a>DOMExceptiona>, and set the <a>user agenta>'s <a>payment
|
938 | 939 | request is showinga> boolean to false.
|
939 | 940 | li>
|
| 941 | + <li>Otherwise, present a user interface that will allow the user to |
| 942 | + interact with the <var>handlersvar>. The user agent SHOULD |
| 943 | + prioritize the preference of the user when presenting payment |
| 944 | + methods. |
| 945 | + li> |
| 946 | + <li data-tests= |
| 947 | + "show-method-optional-promise-rejects-manual.https.html, show-method-optional-promise-resolves-manual.https.html"> |
| 948 | + If <var>detailsPromisevar> was passed, then: |
| 949 | + <ol> |
| 950 | + <li>Set <var>requestvar>.<a>[[\updating]]a> to true. |
| 951 | + li> |
| 952 | + <li>Disable the user interface user interface that will allow the |
| 953 | + user to interact with the <var>handlersvar> |
| 954 | + li> |
| 955 | + <li>Run the <a>update a <code>PaymentRequestcode>'s details |
| 956 | + algorithma> with <var>detailsPromisevar> and |
| 957 | + <var>requestvar>. |
| 958 | + li> |
| 959 | + <li>Wait for the <var>detailsPromisevar> to settle. |
| 960 | + <p class="note"> |
| 961 | + Based on how the <var>detailsPromisevar> settles, the |
| 962 | + <a>update a <code>PaymentRequestcode>'s details |
| 963 | + algorithma> determines how the payment UI behaves. That is, |
| 964 | + <a>upon rejectiona> of the <var>detailsPromisevar>, the |
| 965 | + payment request aborts. Otherwise, <a>upon fulfillmenta> |
| 966 | + <var>detailsPromisevar>, the user agent re-enables the |
| 967 | + payment request UI and the payment flow can continue. |
| 968 | + p> |
| 969 | + li> |
| 970 | + ol> |
| 971 | + li> |
940 | 972 | <li>
|
941 | 973 | <p>
|
942 | 974 | Otherwise, present a user interface to allow the user to interact
|
|
3346 | 3378 | <li>Set <var>requestvar>.<a>[[\updating]]a> to false.
|
3347 | 3379 | li>
|
3348 | 3380 | <li>The <a>user agenta> SHOULD update the user interface based
|
3349 |
| - on any changed values in <var>requestvar>. The user agent |
3350 |
| - SHOULD re-enable user interface elements that might have been |
3351 |
| - disabled in the steps above if appropriate. |
| 3381 | + on any changed values in <var>requestvar>. If appropriate, the |
| 3382 | + user agent SHOULD re-enable user interface elements that might |
| 3383 | + have been disabled prior to running this algorithm. |
3352 | 3384 | li>
|
3353 | 3385 | ol>
|
3354 | 3386 | li>
|
|
0 commit comments