- From: Domenic Denicola <notifications@github.com>
- Date: Thu, 23 Aug 2018 12:08:24 -0700
- To: w3c/payment-request <payment-request@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/payment-request/pull/751/review/149052488@github.com>
domenic requested changes on this pull request. Overall makes sense; some things to fix > + <dfn>MerchantValidationEvent</dfn> interface + </h2> + <pre class="idl"> + [Constructor(DOMString type, optional MerchantValidationEventInit eventInitDict), SecureContext, Exposed=Window] + interface MerchantValidationEvent : Event { + readonly attribute USVString validationURL; + void complete(Promise<any> merchantSessionPromise); + }; + </pre> + <section> + <h3> + <dfn data-lt= + "MerchantValidationEvent.MerchantValidationEvent()"><code>MerchantValidationEvent</code> + Constructor</dfn> + </h3> + <p data-tests= This may be new technology since we last worked on this, but now we have https://dom.spec.whatwg.org/#concept-event-constructor-ext. You should define "event constructing steps" for MerchantValidationEvent which: - set [[waitForUpdate]] etc. - Validate/normalize/set the default for the validationURL attribute (no internal slot for event attributes). > + </h2> + <pre class="idl"> + [Constructor(DOMString type, optional MerchantValidationEventInit eventInitDict), SecureContext, Exposed=Window] + interface MerchantValidationEvent : Event { + readonly attribute USVString validationURL; + void complete(Promise<any> merchantSessionPromise); + }; + </pre> + <section> + <h3> + <dfn data-lt= + "MerchantValidationEvent.MerchantValidationEvent()"><code>MerchantValidationEvent</code> + Constructor</dfn> + </h3> + <p data-tests= + "MerchantValidationEvent/constructor.https.html, MerchantValidationEvent/constructor.http.html"> The internal slots list, both in the constructor and in the table, seem incomplete. The constructor initializes waitForUpdate and validationURL. (validationURL should not be an internal slot.) The table lists request and validationURL. The complete() method operates on request and waitForUpdate. > + <h3> + <dfn data-lt= + "MerchantValidationEvent.MerchantValidationEvent()"><code>MerchantValidationEvent</code> + Constructor</dfn> + </h3> + <p data-tests= + "MerchantValidationEvent/constructor.https.html, MerchantValidationEvent/constructor.http.html"> + The <a data-lt= + "MerchantValidationEvent"><code>MerchantValidationEvent(<var>type</var>, + <var>eventInitDict</var>)</code></a> constructor MUST act as + follows: + </p> + <ol class="algorithm"> + <li>Let <var>base</var> be the <a data-cite= + "dom#context-object">context object</a>’s <a data-cite= + "!html/multipage/webappapis.html#relevant-settings-object">relevant There is no context object in constructors. But once you use event constructing steps you can use _event_'s relevant settings object. > + <tr> + <th> + Internal Slot + </th> + <th> + Description (<em>non-normative</em>) + </th> + </tr> + <tr> + <td> + <dfn data-lt="MVE.[[request]]" data-lt-nodefault= + "">[[\request]]</dfn> + </td> + <td> + The <a>PaymentRequest</a> instance that instantiated this + <a>PaymentResponse</a>. "this" is not a PaymentResponse, so this doesn't seem right... > + <li>Let <var>request</var> be <var>event</var>.<a data-lt= + "MVE.[[request]]">[[\request]]</a>. + </li> + <li>If <var>request</var>.<a>[[\state]]</a> is not + "<a>interactive</a>", then <a>throw</a> an + "<a>InvalidStateError</a>" <a>DOMException</a>. + </li> + <li>If <var>request</var>.<a>[[\updating]]</a> is true, then + <a>throw</a> an "<a>InvalidStateError</a>" <a>DOMException</a>. + </li> + <li>Set <var>event</var>'s <a>stop propagation flag</a> and <a>stop + immediate propagation flag</a>. + </li> + <li>Set <var>event</var>.<a>[[\waitForUpdate]]</a> to true. + </li> + <li>Run the <a>validate a merchant algorithm</a> with Wrong algorithm > + </h2> + <p> + <dfn>Merchant validation</dfn> is the process by which a <a>payment + handler</a> validates the identity of a merchant. Validated merchants + are allowed to interface with a <a>payment handler</a>. Details of + how actual validation is performed is outside the scope of this + specification. + </p> + <p> + It is OPTIONAL for a payment handler to support <a>merchant + validation</a>. + </p> + <p> + For <a>payment methods</a> that support <a>merchant validation</a>, + the user agent runs the <dfn>validate a merchant algorithm</dfn>. The + algorithm takes a USVString <var>merchantSpecificURL</var>, provided Either link/code-ify USVString or use [scalar value string](https://infra.spec.whatwg.org/#scalar-value-string). > + </li> + </ol> + </li> + <li> + <a>Upon fulfillment</a> of <var>opaqueDataPromise</var> with value + <var>opaqueData</var>: + <ol> + <li>If <var>opaqueData</var> is invalid, as per the validation + rules of the <a>payment handler</a>, <a>abort the update</a> with + <var>request</var> and an appropriate <a data-cite= + "!webidl#dfn-exception">exception</a> and return. + </li> + <li>Otherwise, set <var>request</var>.<a>[[\updating]]</a> to + false. + </li> + <li>Enable user interface, allowing the request for payment to Missing "the" -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/payment-request/pull/751#pullrequestreview-149052488
Received on Thursday, 23 August 2018 19:08:46 UTC