* Compare address timeLastModified as well as the selectedShippingAddress guid when handling new state
* Add tests to ensure editing or removing the selected address record correctly updates the UI
MozReview-Commit-ID: InQDP55Fs2
If a property gets cleared in autofill storage, that property is not defined on the object when retrieved which means it won't get updated.
Previously I thought that known fields were always returned and had a default value.
MozReview-Commit-ID: KnBrpFdOk8P
* Add an observed attribute to address-picker to render when address-fields is changed
* Add a filter step to address-picker, to exclude addresses that represent duplicates given the requested fields
* Filter out addresses that do not contain one or more of the requested fields
* Use a default set of fields to establish duplicates and meet the bar for adding an address as an option
MozReview-Commit-ID: 7lg4suNHv60
This allows custom elements to work in any document in the parent process that
allows XUL and XBL. The test takes the easy option of moving the existing XUL
custom element test to a run with the custom element pref disabled.
MozReview-Commit-ID: CMiLzmp60jA
* Based on original patch by MattN
* Make stored contacts available as payer data (MattN)
* Add the address-picker element to the dialog for selecting payer details from stored contacts (MattN)
* Add a field-names attribute to the payer address-picker, populated from the request paymentOptions
* Basic CSS to selectively render address fields
* Add mochitests to verify paymentOptions result in the correct payment picker behavior
MozReview-Commit-ID: Br8i5MVyeQ3
* Based on original patch by MattN
* Make stored contacts available as payer data (MattN)
* Add the address-picker element to the dialog for selecting payer details from stored contacts (MattN)
* Add a field-names attribute to the payer address-picker, populated from the request paymentOptions
* Basic CSS to selectively render address fields
* Add mochitests to verify paymentOptions result in the correct payment picker behavior
MozReview-Commit-ID: Br8i5MVyeQ3
* Add a serializeRequest method to paymentDialogWrapper to correctly serialize the nsIArray values
* Test results of serializing a request with multiple displayItems, shippingOptions, paymentMethods and modifiers
MozReview-Commit-ID: DTqzTAjvdxq
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
* The order-details container arranges and populates the items list and the 2nd total line under the items.
* The displayItems list is rendered into 2 lists, a "footer-items" list which displays tax and similar items just before the total, and a "main" list for everything else.
* The list items are instances of a payment-details-item component
* Initial layout of the line items and total with css grid
* Tests for order-details component
* Tests for payment-detail-item component
MozReview-Commit-ID: 68r8SSgwHgq