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 {, <
Marcos Cáceres
Dorel Luca
Jeff Gilbert
Henri Sivonen
Sebastian Hengst
Blake Kaplan
Joel Maher
Eden Chuang
YUKI "Piro" Hiroshi
Kris Maglione
Tristan Bourvon
Boris Zbarsky
Jonathan Guillotte-Blouin
Jared Wein
Andreea Pavel
Andrew McCreight
Cameron McCormack
Cosmin Sabou
Brindusan Cristian
Eden Chuang
Masatoshi Kimura