There isn't any need to create an actor per call to the parent. This patch
lines up PaymentRequest with PPaymentRequestChild objects and links them
together. It also simplifies the maps and arrays we use to keep track of these
objects.
There's one tricky bit to note in this patch: in the case that a promise is
passed to paymentRequest.show(), we don't notify the parent process until the
promise resolves (when we call either UpdatePayment or AbortUpdate). In that
case, I needed to distinguish between an "update" because of the promise
resolving or a call to updateWith on an shippingaddresschange event in order
to get the bookkeeping right with the mActivePayments hashtable. In that case,
the PaymentRequest is kept alive by mShowingRequest alone. In all other cases,
mActivePayments keeps the PaymentRequest alive until we resolve or reject the
correct promise.
MozReview-Commit-ID: HoHjn8eqC4T
--HG--
extra : rebase_source : 4da1d65d1f791f4a5c18871ab3a3dcf94e833b90
1. Add "optional Promise<PaymentDetailsUpdate> detailsPromise" as a parameter
of PaymentRequest.show() in PaymentRequest.webidl.
2. Let PaymentRequest inherit from PromiseNativeHandler, and implement the
ResolvedCallback() and RejectedCallback() to handle the PaymentDetailsUpdate
promise.
3. Update PaymentRequest.show() implementation. If PaymentDetailsUpdate Promise
is not nullptr, the show request would not be transferred to chrome process
immediately until the promise is resolved/rejected.
4. Update selectedShippingOption when requestShipping is true.
5. Change the PaymentMethod id validation sequence according to the spec.
--HG--
extra : histedit_source : e591c759037cce4f66701b2faa5ecbe01c00e246
This was automatically generated by the script modeline.py.
MozReview-Commit-ID: BgulzkGteAL
--HG--
extra : rebase_source : a4b9d16a4c06c4e85d7d85f485221b1e4ebdfede
This patch implements payment method identifier validation algorithm
according to the spec https://w3c.github.io/payment-method-id/.
The steps to validate a payment method identifier with a string pmi are
given by the following algorithm. It returns true if the pmi is valid.
1. Let url be the result of running the basic URL parser with pmi.
2. If url is failure, validate a standardized payment method identifier with
pmi and return the result.
3. Otherwise, validate a URL-based payment method identifier passing url and
return the result.
This patch implements currency validation algorithm according to the spec
https://w3c.github.io/payment-request/#validity-checkers.
1. amount.currencySystem must be "urn:iso:std:iso:4217".
2. amount.currency is valid with following criteria
1. The currency length must be 3.
2. The currency contains any character that must be in the range "A" to
"Z"(U+0041 to U+005A) or the range "a" to "z"(U+0061 to U+007A).
According to the spec, converting the currency to upper case and save it in
nsIPaymentRequest.
1. Create a new action response status PAYMENT_NOTSUPPORTED and get rid of
unnecessary method isAccpeted() from nsIPaymentActionResponse.idl.
2. Create canMakePayment() in PaymentRequestService and run it before
launching UI. If canMakePayment() returns false, send PAYMENT_NOTSUPPORTED
back to content process.
3. If chrome process returns PAYMENT_NOTSUPPORTED when calling showPayment(),
throw NotSupportedError DOMException to merchant side.
Per spec, given details and options parameters of PaymentRequest constructor,
1) if details.shippingOptions exists and IDs of all shipping options are unique,
request's shippingOption will be set to the last selected option's ID.
Otherwise, set request's shippingOption to null.
2) if options.requestShipping is ture, set request's shippingType to
options.shippingType. Otherwise, set request's shippingType to null.
Marcos Cáceres
Blake Kaplan
Eden Chuang
Henri Sivonen
Andreea Pavel
Andrew McCreight
Eden Chuang
Jocelyn Liu
Alphan Chen
Wes Kocher
Ryan VanderMeulen