1. Add a new method nsIPaymentRequestService::ChangePaymentMethod for UI to
inform merchant the payment method is changed by user.
2. Add a new method in PPaymentRequest.ipdl to passing the changing method
information from chrome process to content process.
3. Add BasicCardChangeDetails dictionary in BasicCardPayment.webidl
4. Create ChangeDetails, GeneralDetails and BasicCardDetails for saving the
the method information in content process.
--HG--
extra : histedit_source : 8426da9c1d070daa35623b3431341c13cb361aed
1. Add a new method nsIPaymentRequestService::ChangePaymentMethod for UI to
inform merchant the payment method is changed by user.
2. Add a new method in PPaymentRequest.ipdl to passing the changing method
information from chrome process to content process.
3. Add BasicCardChangeDetails dictionary in BasicCardPayment.webidl
4. Create ChangeDetails, GeneralDetails and BasicCardDetails for saving the
the method information in content process.
1. Adding a new completeStatus 'initial' for nsIPaymentRequest.completeStatus
to indicate the status of the showing PaymentRequest for Payment UI component.
2. Removing the PaymentRequest::mDeferredShow and calling
PaymentRequestManager::showPayment() when PaymentRequest::Show() called
with a detailsUpdate parameter to inform UI component to support better
user experience.
In original design, payment method response data is passed between processes
through a simple nsString. It means a special encoder/decoder is needed for
special response data, ex. BasicCardResponse, to serialize/deserialize
into/from the nsString. However, when a token spliter, ':', ';' and '@', is
used in response data, it makes the encoder/decoder can not work normally.
It is hard to define a suitable token spliter set for encoder/decoder.
So instead of using an error-prone encoder/decoder, this patch defining a new
IPC structure for response data.
--HG--
extra : rebase_source : 4972033516bc861ea3f975a27b7688fc6eb89a94
Removing PaymentRequestManager::mShowingRequest and related code.
PaymentRequest showing is controlled by PaymentRequestService in chrome
process, before we come out the solution for bug 1469419, we don't need
showing control in content process.
To support merchants providing the payment details with errors by
PaymentRequestUpdateEvent.updateWith() during PaymentResponse.retry(),
PaymentDetailsUpdate needs to add more two attributes in webidl.
dictionary PaymentDetailsUpdate {
...
PayerErrorFields payerErrors;
object paymentMethodErrors;
};
And transfer these error field to UI component
1. Add PaymentValidationErrors and PayerErrorFields in PaymentRequest.webidl
and PaymentResponse.retry() in PaymentResponse.webidl
2. Implement PaymentRequest.retryPayment() and
PaymentRequestManager.retryPayment() in content process.
3. Add IPCPaymentRetryActionRequest in PPaymentRequest.ipdl to transfer the
error fields to chrome process.
4. Implement PaymentResponse.retry() by reusing the code of show() and
updateWith() of PaymentRequestService in chrome process.
1. Returning NS_ERROR_FAILURE in PaymentRequestService::RespondPayment() when
the specified PaymentRequest does not exist in PaymentRequestService.
2. Renaming "cleanup" to "close" in DOM::WebPayment codes to fit the actual
behavior.
Let PaymentRequest inherit from nsIDocumentActivity interface.
Calling RegisterActivityObserver() and UnregisterActivityObserver() in
constructor and destructor to get activity notifications from document.
When receiving the notification, NotifyOwnerDocumentActivityChanged() will
check the owner document's activity status. If the status is disabled, calling
PaymentRequestManager::CleanupPayment() to cleanup the PaymentRequest in
content process and aslo sending the cleanup information to chrome process.
If we end up shutting down the content process while there's a request active
we'll end up "leaking" the request and asserting. This makes sure that we
let go of the PaymentRequest in that edge case. I can cause this by forceably
closing the payment request window on Linux without hitting OK or cancel.
MozReview-Commit-ID: 6XDYIcqNkC6
--HG--
extra : rebase_source : d20d8fae4aa4fc3afcca8491d415c64b8af8bcb4
The existing code only passed strings around to identify PaymentRequest
objects. That meant that we were constantly having to do hashtable lookups to
find the corresponding object. This patch just uses the single map that IPDL
maintains for us and passes objects around, obviating the need for more
hashtable lookups.
MozReview-Commit-ID: 6BBonrc6q4x
--HG--
extra : rebase_source : 041c6ce742d60a2c9e954a58582d09cd9ef7f2b1
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
This removes some hard tabs that crept in and combines two if branches into a
single statement in order to avoid a bit of duplication.
The existing code here seems to treat any sort of upcast as needing a QI. That
is needlessly wasteful and causes a bunch of unneeded virtual calls.
MozReview-Commit-ID: 7WshYm9C4Xb
--HG--
extra : rebase_source : bc7b1b5157324158f627efd8dff54f078488f4fc
The existing code assumed that the only reason that there could be a
PaymentRequestChild was due to an active show() call. That is not the case. We
already know whether there's an "interactive" PaymentRequest through
mShowingRequest, so we should just use that instead.
MozReview-Commit-ID: IA9bXn7hS63
--HG--
extra : rebase_source : 0d65a6e05d224a5fddfdbb953ad28f2eecd80533
1. Add AddressErrors in PaymentRequest.webidl.
2. IPC for passing AddressErrors.
3. Getters for AddressErrors in nsIPaymentDetails.
--HG--
extra : rebase_source : 64c57003d57e064b5284cc64447c0c0740f16121
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 the following changes according to the spec change.
See https://w3c.github.io/payment-request/#constructor step 8 for more
details.
1. Return TypeError during PaymentRequest construction with duplicate
shippingOption id.
2. Set PaymentRequest.shippingOption with the selected shippingOption only
if options.requestShipping is true.
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.
Getting the top level document's principal when constructing PaymentRequest,
then sending it to chrome process and saving it in nsIPaymentRequest.
Creating a new readonly attribute nsIPrincipal topLevelPrincipal in
nsIPaymentRequest for UI to query the top level document's principal
information.
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.
