1. Add testcase testRetryAfterComplete to test the behavior of retry() after
complete().
2. Add testcase testRetryAfterRetry to test the multiple retry()s in the same
round.
3. Add testcase testRetryWithEmptyErrors to test the retry() called with an
empty PaymentValidationErrors.
4. Add testcase testRetry to test the normal flow of retry().
5. Add testcase testRetryAbortByUser to test the retry() aborted by user.
1. Improving the testCloseByRedirectingAfterShow. Try to call
PaymentRequestService::respondPayment when the PaymentRequest is closed.
2. Adding a new test testUpdateWithRespondedPayment for the case the merchant
calls PaymentRequestUpdateEvent::updateWith() and the PaymentRequest is
rejected by the user.
--HG--
rename : dom/payments/test/test_cleanupPayment.html => dom/payments/test/test_closePayment.html
1. Checking if the PaymentRequest::mState equals to eInteractive when calling
PaymentRequest::UpdatePayment() and PaymentRequest::AbortUpdate.
2. Removing the non-suitable MOZ_ASSERT in PaymentRequest::RespondShowPayment()
1. Adding a new method void closePayment(in AString requestId) in
nsIPaymentUIService.idl
2. Implementing the closePayment method in paymentUIService.js.
3. Calling closePayment of paymentUIService.js in
PaymentRequestService::LaunchUIAction()
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.
This allows JS callers to automatically get the correct types during
interation, without having to explicitly specify them.
Differential Revision: https://phabricator.services.mozilla.com/D3728
--HG--
extra : rebase_source : b708f382d8ea571d199c669bfed5b5a7ca9ffac4
extra : histedit_source : 7df6feb82088c8a5ca45dc28fe4d2b852c177fee
In order to allow JS callers to use nsISimpleEnumerator instances with the JS
iteration protocol, we'll need to additional methods to every instance. Since
we currently have a large number of unrelated implementations, it would be
best if they could share the same implementation for the JS portion of the
protocol.
This patch adds a stub nsSimpleEnumerator base class, and updates all existing
implementations to inherit from it. A follow-up will add a new base interface
to this class, and implement the additional functionality required for JS
iteration.
Differential Revision: https://phabricator.services.mozilla.com/D3725
--HG--
extra : rebase_source : ad66d7b266856d5a750c772e4710679fab9434b1
extra : histedit_source : a83ebffbf2f0b191ba7de9007f73def6b9a955b8
1. add a set new mochitests to test cleanup function.
By redirecting to another page.
By redirecting to another page, when PaymentRequest.show() is called.
By reloading
By removing/closing the page.
2. remove unnecessary PaymentRequestService.cleanup() call in the test suite.
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.
We only build the frontend parts of Web Payments on Nightly, but users could
futz with the prefs and expose the DOM API on Beta. We should be careful about
not allowing that mismatch.
This also adds some additional logging if we run into a bug like this again.
MozReview-Commit-ID: 9qcQTIsIHkg
--HG--
extra : rebase_source : cdaed71d79e6f8cedd1229ffd03cac21e3660367
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
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
This patch includes followings
1. Test with no selected shipping options.
2. Test with one selected shipping option when creating PaymentRequest.
3. Test with multiple selected shipping options when creating PaymentRequest.
4. Test with selecting shipping option by user.
5. Test with modifying the user selection by merchant.
6. Merges the mochitest for bug 1443914.
--HG--
rename : dom/payments/test/Bug1443914ChromeScript.js => dom/payments/test/ShippingOptionsChromeScript.js
rename : dom/payments/test/test_bug1443914.html => dom/payments/test/test_shippingOptions.html
extra : histedit_source : 19126dcb3870e0637ed8f4d0fbc6839cb5d682a0
1. Add testShowWithXXX tests to test PaymentRequest.show() with
PaymentDetailsUpdate promise.
2. Improve the test case implementation by removing the redundant code.
--HG--
extra : histedit_source : 9c68ba8eb6ea4db7e6a158baf19f170b5736a9db
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
Update the implementation according to the spec update.
Force updating the saved PaymentDetails when requestShipping is true, even
the data(shippingOptions) doesn't present in the DetailsUpdate.
--HG--
extra : histedit_source : b0a1c0b9cc7efe045ce330432b60bb6f86eb1878
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
Add a new member mAllowPaymentRequest on nsIDocument and following related
methods,
bool AllowPaymentRequest() const
void SetAllowPaymentRequest(bool aAllowPaymentRequest)
mAllowPaymentRequest is used to check if PaymentRequest is allowed to use on
the document. According to the spec
https://html.spec.whatwg.org/multipage/iframe-embed-object.html#allowed-to-use
the mAllowPaymentRequest should be true under following situations
1. The document is the top level content document.
2. The document is the same origin with its parent document and its parent
document's mAllowPaymentRequest is true.
3. The document is different origin with its parent document but its
parent node is an iframe with allowpaymentrequest flag and the parent
document's mAllowPaymentRquest is true.
This patch also include following mochitests
1. test for allowpaymentrequest flag changing. The flag change effect should
not be applied to the document immediately, it should be updated while
the browsing context is updated.
2. test for effect propagation in the nested iframe.
This was automatically generated by the script modeline.py.
MozReview-Commit-ID: BgulzkGteAL
--HG--
extra : rebase_source : a4b9d16a4c06c4e85d7d85f485221b1e4ebdfede
1. PaymentRequest::PrefEnabled() returns false under non-e10s situation.
2. Add a new mochitest test_block_none10s.html to expect to get ReferenceError
in non-e10s mode.
1. Test PaymentRequest construction with valid PMIs.
2. Test PaymentRequest construction with Invalid PMIs.
3. Test PaymentRequestUpdateEvent::updateWith with a valid PMI.
4. Test PaymentRequestUpdateEvent::updateWith with a invalid PMI.
Remove unnecessary html tags in html files.
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 changes the test_construction.html with following modification.
1. Modify the test testWithDuplicateShippingOptionsParameters to expect a
TypeError when constructing wiht duplicate shippingOption ids.
2. Add test testShippingOtpionAttribute for shippingOption setting checking
with following conditions
1. No selected shippingOption and PaymentOptions.requestShipping is false
2. One selected shippingOption and PaymentOptions.requestShipping is false
3. One selected shippingOption and PaymentOptions.requestShipping is true
4. Multiple selected shippingOptions and PaymentOptions.requestShipping is
true.
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.
1. Create a new test test_currency_amount_validation.html to test validation
with following scenarios
* test with well formed currency codes.
* test with invalid currency codes.
* test with valid lower case currency codes and check is it converted to
upper case.
* test with invalid currency codes while calling
PaymentRequestUpdateEvent::updateWith().
* test with invalid amount value with calling
PaymentRequestUpdateEvent::updateWith().
2. Move tests of test_validate_decimal_value.html to
test_currency_amount_validation.html
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.
Replace it with NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION, because it
has been the same for a while.
MozReview-Commit-ID: 5agRGFyUry1
--HG--
extra : rebase_source : 5388c56b2f6905c6ef969150f0c5b77bf247624d
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.
1. Adding new checks in ConstructorChromeScript.js to checking the top level
document's principal information.
2. Adding a new test testCrossOriginTopLevelPrincipal in
test_constructor.html to testing the topLevelPrincipal attribute under
cross origin situation.
3. Removing some useless mochitest browser-chrome testcase.
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.