For Nightly users who already have credit cards saved in their profile, we will do a one-off upgrade of their encrypted credit card number.
This only applies to users who have NO master password set, to avoid showing them the master password prompt when we migrate.
For those who did, we would quietly delete their credit card record from the store.
Differential Revision: https://phabricator.services.mozilla.com/D8029
For Nightly users who already have credit cards saved in their profile, we will do a one-off upgrade of their encrypted credit card number.
This only applies to users who have NO master password set, to avoid showing them the master password prompt when we migrate.
For those who did, we would quietly delete their credit card record from the store.
Differential Revision: https://phabricator.services.mozilla.com/D8029
* A new accepted-cards element to represent the labeled list of card icons
* Add the accepted cards section to the summary and card add/edit page
* mochitest for the accepted-cards element
* Make cc-type a required field and validate it against the list of supported networks
* Add verification of the pay button disabling when card network is not supported
Depends on D5823
Differential Revision: https://phabricator.services.mozilla.com/D5824
* A new accepted-cards element to represent the labeled list of card icons
* Add the accepted cards section to the summary and card add/edit page
* mochitest for the accepted-cards element
* Make cc-type a required field and validate it against the list of supported networks
* Add verification of the pay button disabling when card network is not supported
Depends on D5823
Differential Revision: https://phabricator.services.mozilla.com/D5824
This is easier to understand as we don't have to round-trip the whole success and error states to the privileged wrapper which could potentially lead to stale state changes.
This is also much simpler for the basic-card-form as it doesn't need a lot of the complexity of the previous implementation.
* Move selectedStateKey from page to address-page since it doesn't apply to basic-card-page
MozReview-Commit-ID: B4kiZNWElGI
This is easier to understand as we don't have to round-trip the whole success and error states to the privileged wrapper which could potentially lead to stale state changes.
This is also much simpler for the basic-card-form as it doesn't need a lot of the complexity of the previous implementation.
* Move selectedStateKey from page to address-page since it doesn't apply to basic-card-page
MozReview-Commit-ID: B4kiZNWElGI
* A new CompletionErrorPage / completion-error-page element which represents the content of the completion error
* Leave the dialog open when complete() results in a 'fail' or 'timeout'.
* The 'done' button on the fail & timeout error page closes the dialog by sending a message up to the paymentDialogWrapper.
* Rewrite the pay button rendering logic to ensure it is disabled when it should be
* Retry handling and UI not addressed here. Will need a new bug when the DOM support has landed.
* Extend completeStatus support in debugging.html and group like actions to tidy up a bit
MozReview-Commit-ID: GDhJqrj14uT
* Add tests to verify that the dialog stays open when completion fails or times out
* Add tests to verify that complete() throws after the timeout
* Rework completeStatus mochitest for PaymentDialog
MozReview-Commit-ID: 4ZNVEYMp7h5
