***
Removed IPC References in PCContent
***
Removed IPC References on nsContentPermissionHelper
***
Remove IPC Principal from PBrowser
***
Remove IPCPrincipal from the PaymentRequest
***
Remove IPCPrincipal from the PPresentation
***
Remove IPC Principal from PNecko
Differential Revision: https://phabricator.services.mozilla.com/D28650
--HG--
extra : moz-landing-system : lando
This is split from the previous changeset since if we include dom/ the file size is too
large for phabricator to handle.
This is an autogenerated commit to handle scripts loading mochitest harness files, in
the simple case where the script src is on the same line as the tag.
This was generated with https://bug1544322.bmoattachments.org/attachment.cgi?id=9058170
using the `--part 2` argument.
Differential Revision: https://phabricator.services.mozilla.com/D27457
--HG--
extra : moz-landing-system : lando
There are few things that are either Fennec-specific or don't work
currently under GeckoView w/ e10s under TestRunnerActivity. Disable
these so we can get some testing going in automation.
This also replaces 'isFennec' with the more correct 'is_fennec'.
Differential Revision: https://phabricator.services.mozilla.com/D19016
--HG--
extra : moz-landing-system : lando
For cases where the class has direct calls (that is, we cast `this` to the
subclass before making the call) no longer declare Recv/Answer methods on the
base class at all. This should ensure that slots for them are not generated in
vtables, and also allow the derived class to choose the method signature (e.g.
whether it wants to take something by reference or by value).
Differential Revision: https://phabricator.services.mozilla.com/D18132
--HG--
extra : moz-landing-system : lando
When calling a Recv/Alloc/Dealloc method on most types, cast `this` to the
derived class.
There is a heuristic to figure out what the correct derived type is. There is a
blacklist of types which we can't do direct calls on for the moment, as well as
an override for types that do work with direct calls but which don't match the
heuristic.
Differential Revision: https://phabricator.services.mozilla.com/D16492
--HG--
extra : moz-landing-system : lando
The current document of a window can change in between the time when a
PaymentRequest registers as an activity observer and when it attempts
to unregister, so keep a strong reference to the document. This is the
same issue as bug 1317805.
Differential Revision: https://phabricator.services.mozilla.com/D17540
--HG--
extra : moz-landing-system : lando
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
1. Warning to browser console when calling with empty error fields.
2. Warning to browser console when calling with non-empty payer errors but
corresponding PaymentOptions.requestPayerXXX is false.
--HG--
extra : histedit_source : 816c44a0ceca5202886a48eee96d2ef7f7315487
PaymentRequest API is not supported when the PaymentRequest is not in the
fully active document. Adding bool a PaymentRequest::InFullyActiveDocument()
method to check if the PaymentRequest is in fully active document. This
method should be called at the start of any PaymentRequest APIs. If the
PaymentRequest is not in fully active document, ignoring the API call and
throw the NS_ERROR_DOM_ABORT_ERR if needed.
--HG--
extra : histedit_source : 3e8e4a73f69c639f9cc528afa586af22597ff320
1. Set nsIPaymentRequest.completeStatus as 'updating' when calling
nsIPaymentRequestService::Change*. After event handling done, set
nsIPaymentRequest.completeStatus as '' and call
nsIPaymentUIService::UpdatePayment()
2. When the page handles PaymentRequestUpdateEvent or the Promise of
PaymentRequest::Show() over the dom.payments.response.timeout, set
nsIPaymentRequest.completeStatus as 'timeout' and call
PaymentUIService::UpdatePayment() automatically
3. Set nsIPaymentRequest.completeStatus as 'nohandler' when dispatching
PaymentRequestUpdateEvent and no event handler for it.
4. Set the initial valud of dom.payments.response.timeout to 20000 ms.
--HG--
extra : rebase_source : 7fe64a05bf7d20726c95aadd6e85bc14cb26bd3f
Save the changing method information in PaymentMethodChangeEvent and
dispatch it.
--HG--
extra : histedit_source : 583cc4efd19d22d21864527db9bb479f772839e4
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 attribute nsIPaymentOptions.requestBillingAddress.
2. Add new XPCOM interfaces MethodChangeDetails, GeneralChangeDetails and
BasicCardMethodChangeDetails for passing the method change details from
UI code.
--HG--
extra : histedit_source : 680bff71f0d8a9d9333a3699fcc6a4fd9630fe1b
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. Add a new attribute nsIPaymentOptions.requestBillingAddress.
2. Add new XPCOM interfaces MethodChangeDetails, GeneralChangeDetails and
BasicCardMethodChangeDetails for passing the method change details from
UI code.
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.
The concept of card types, supportedTypes, BasicCardType enum, were removed from the Basic Card spec.
Differential Revision: https://phabricator.services.mozilla.com/D10646
--HG--
extra : moz-landing-system : lando
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
If class A is derived from class B, then an instance of class A can be
converted to B via a static cast, so a slower QI is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D6861
--HG--
extra : moz-landing-system : lando
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.
1. Adding a checking before clearing PaymentRequestService::mShowingRequest.
Clearing PaymentRequestService::mShowingRequest when it is rejected.
2. Adding an internal method nsresult ShowPayment(const nsAString& requestId)
to remove the duplicate code in PaymentRequestService.
Add state checking when calling RespondPayment(), ChangeShippingAddress()
and ChangeShippingOption().
Calling ChangeShippingXXX is valid when the PaymentRequest state is interactive.
Calling RespondPayment is valid when following situations
1. PaymentRequest state is interactive
2. PaymentRequest state is closed but the response is for CompleteAction.
3. PaymentRequest state is created but the response is for CanMakeAction.
--HG--
extra : histedit_source : 9ae63e409813154de42cc33024835ac5f0c96893
Adding testcase for interacting with PaymentRequest in wrong PaymentRequest
state. Calling RespondPayment(), ChangeShippingOption() and
ChangeShippingAddress() in wrong state should return error. This test case
verifying the behavior when calling these methods when PaymentRequest state
is eClosed and after PaymentResponse::complete() called.
--HG--
extra : histedit_source : 3e70e64ac739dd7d8cbc4627dbdbd64462ae4211
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.
Remove the unnecessary XPCOM component nsIPaymentActionRequest and
nsIPaymentActionCallback. These two components are only used in C++ and they
need not to expose to the front end.
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