diff --git a/index.html b/index.html index 825fe2b..4b54c1a 100644 --- a/index.html +++ b/index.html @@ -1095,7 +1095,7 @@

readonly attribute FrozenArray<PaymentDetailsModifier> modifiers; readonly attribute DOMString instrumentKey; Promise<WindowClient?> openWindow(USVString url); - void respondWith(Promise<PaymentHandlerResponse>handlerResponse); + void respondWith(Promise<PaymentHandlerResponse>handlerResponsePromise); };
@@ -1199,12 +1199,15 @@

- respondWith() method + respondWith() method

This method is used by the payment handler to provide a PaymentHandlerResponse when the payment successfully - completes. + completes. When called, it runs the Respond to PaymentRequest + Algorithm with event and + handlerResponsePromise as arguments.

or a fallback image provided by the user agent. + + + [[\respondWithCalled]] + + + false + + + YAHO + +

@@ -1709,9 +1723,9 @@

The user agent receives a successful response from the payment handler through resolution of the Promise provided to the respondWith() - function of the corresponding PaymentRequestEvent - dictionary. The application is expected to resolve the Promise with - a PaymentHandlerResponse instance containing the payment + function of the corresponding PaymentRequestEvent interface. + The application is expected to resolve the Promise with a + PaymentHandlerResponse instance containing the payment response. In case of user cancellation or error, the application may signal failure by rejecting the Promise.

@@ -1733,40 +1747,124 @@

- Extention to User Accepts the Payment Request Algorithm + Respond to PaymentRequest Algorithm

- If the Promise is successfully resolved, the user agent MUST run the - user accepts the payment request algorithm as defined in - [[!payment-request]], replacing steps 6 and 7 with these steps or - their equivalent: + When this algorithm is invoked with event and + handlerResponsePromise parameters, the user agent MUST run + the following steps:

-
    -
  1. Set handlerResponse to the - PaymentHandlerResponse instance used to resolve the - PaymentRequestEvent.respondWith() Promise. +
      +
    1. If event's dispatch flag is unset, then + throw an "InvalidStateError" DOMException and + abort these steps.
      2. -
    2. If handlerResponse.methodName is not present or - not set to one of the values from - PaymentRequestEvent.methodData, run the payment - app failure algorithm and terminate these steps. +
    3. If event.[[\respondWithCalled]] is true, throw + an "InvalidStateError" DOMException and abort these + steps.
      4. -
    4. Create a structured clone of - handlerResponse.methodName and assign it to - response.methodName. +
    5. Set event.[[\respondWithCalled]] to true.
      6. -
    6. If handlerResponse.details is not present, - run the payment app failure algorithm and terminate these - steps. +
    7. Set the event's stop propagation flag and + event's stop immediate propagation flag. +
      8. +
    8. Add handlerResponsePromise to the event's + extend lifetime promises +
      9. +
    9. Increment the event's pending promises count by + one. +
      10. +
    10. Upon rejection of handlerResponsePromise: +
        +
      1. Run the payment app failure algorithm and terminate + these steps. +
        2. +
      +
      11. +
    11. Upon fulfillment of handlerResponsePromise: +
        +
      1. Let handlerResponse be the result of + converting value to a PaymentHandlerResponse + dictionary. If this throws an exception, run the + payment app failure algorithm and terminate these steps. +
        2. +
      2. If handlerResponse.methodName is not present + or not set to one of the values from + event.methodData, + run the payment app failure algorithm and terminate + these steps. +
        3. +
      3. If handlerResponse.details is not present or + not JSON-serializable, run the payment app failure + algorithm and terminate these steps. +
        4. +
      4. Let serializeMethodName be the result of + StructuredSerialize + with handlerResponse.methodName. Rethrow any + exceptions. +
        5. +
      5. Let serializeDetails be the result of + StructuredSerialize + with handlerResponse.details. Rethrow any + exceptions. +
        6. +
      6. The user agent MUST run the user accepts the payment + request algorithm as defined in [[!payment-request]], + replacing steps 7 and 8 with these steps or their equivalent. +
          +
        1. Let methodName be the result of + StructuredDeserialize + with serializeMethodName. Rethrow any + exceptions. +
          2. +
        2. Let details be the result of StructuredDeserialize with + serializeDetails. Rethrow any exceptions. +
          3. +
        3. If any exception occurs in any of the above steps, then + run the payment app failure algorithm and terminate + these steps. +
          4. +
        4. Assign methodName to associated + PaymentRequest's response.methodName. +
          5. +
        5. Assign details to associated PaymentReqeust's + response.details. +
          6. +
        +
        7. +
      12. -
    12. Create a structured clone of - handlerResponse.details and assign it to - response.details. +
    13. Upon fulfillment or rejection of + handlerResponsePromise, queue a microtask to perform the + following steps: +
        +
      1. Decrement the event's pending promises + count by one. +
        2. +
      2. Let registration be the context object's relevant global object's + associated service worker's containing service worker + registration. +
        3. +
      3. If registration’s uninstalling flag is set, + invoke Try Clear Registration with + registration. +
        4. +
      4. If registration is not null, invoke Try + Activate with registration. +
        5. +

    @@ -1974,17 +2072,44 @@

    The term origin is defined in [[!RFC6454]].
    +
    + Writing Promise-Using Specifications +
    +
    + The terms upon fulfillment and upon + rejection are + defined by [[!PROMISES-GUIDE]]. +
    DOM
    - The term fires (an event) - is defined in [[!DOM4]]. + The term fires (an event), + dispatch flag, + stop propagation + flag, and stop immediate propagation + flag are defined in [[!DOM4]].
    Web IDL
    +

    + When this specification says to throw an error, the user agent must + throw an error as described in [[!WEBIDL]]. When this occurs in a + sub-algorithm, this results in termination of execution of the + sub-algorithm and all ancestor algorithms until one is reached that + explicitly describes procedures for catching exceptions. +

    +

    + The algorithm for converting an ECMAScript value to a dictionary + is defined by [[!WEBIDL]]. +

    DOMException and the following DOMException types from [[!WEBIDL-LS]] are @@ -2034,9 +2159,18 @@

    "!SERVICE-WORKERS#handle-functional-event-algorithm">handle functional event, extend lifetime - promises, and scope URL are defined in - [[!SERVICE-WORKERS]]. + promises,pending promises + count, containing + service worker registration, uninstalling flag, + Try Clear + Registration, Try Activate, and + scope URL are + defined in [[!SERVICE-WORKERS]].