Closed Bug 1477105 Opened 6 years ago Closed 6 years ago

Add a card network dropdown to the credit card add/edit screen

Categories

(Firefox :: WebPayments UI, enhancement, P1)

enhancement

Tracking

()

VERIFIED FIXED
Firefox 63
Tracking Status
firefox63 --- verified

People

(Reporter: MattN, Assigned: sfoster)

References

(Blocks 1 open bug)

Details

(Whiteboard: [webpayments] [user-testing])

User Story

* card network dropdown in add/edit
* add CVV field to add/edit when appropriate
* Hide CVV field from payment-summary when appropriate
* Update the persist/save checkbox string to remove the CVV text when it's not applicable

Attachments

(1 file)

The current design involves toggling the CVV field visibility and that should be implemented too here. We'll want to be careful about how we store the network in storage to make sure it doesn't 'cause issues later if we change how we handle card types (debit vs. credit).
(In reply to Matthew N. [:MattN] (PM if requests are blocking you) from comment #0) > The current design involves toggling the CVV field visibility and that > should be implemented too here. This includes adding the CVV field on add/edit pages when applicable based on the network and updating the CVV visibility on the summary page too.
User Story: (updated)
Whiteboard: [webpayments] [triage] → [webpayments] [triage] [user-testing]
Assignee: nobody → jaws
Priority: -- → P1
Whiteboard: [webpayments] [triage] [user-testing] → [webpayments] [user-testing]
Assignee: jaws → nobody
Priority: P1 → --
Whiteboard: [webpayments] [user-testing] → [webpayments] [triage] [user-testing]
Priority: -- → P2
Whiteboard: [webpayments] [triage] [user-testing] → [webpayments] [user-testing]
Flags: qe-verify+
QA Contact: hani.yacoub
Assignee: nobody → sfoster
Status: NEW → ASSIGNED
Priority: P2 → P1
My tentative plan here is to define the network-ids list in one place, in dom/payments somewhere near the #defines we already have in BasicCardPayment.cpp. This way as the list evolves, we are only maintaining it in one place. We'll have a corresponding displayable string for each network-id - for now defined as entities in paymentRequest.xhtml. I'll start by doing the front-end part. At that point I'm likely to need some direction on the DOM part - figuring out where this fits and what the implementation should look like.
Currently, BasicCardForm is a wrapper around the FormAutofill functionality. We render the same form, and lean on those classes for validating and then assembling a record from the form input. We now need UI to allow the user to select the card network in the payment context, and to know if the merchant will accept this card (supportedNetworks) Does that imply we should add this network picker to the formautofill forms & the associated network-id to those records so we can continue sharing this stuff? If not, how do we manage the divergence of these 2 forms, and the data they capture and represent?
Flags: needinfo?(MattN+bmo)
Yes, the card network should be in autofillEditForms and in the same autofill storage so it can be shared.
Flags: needinfo?(MattN+bmo)
Documenting a few decisions & consequences: * Cards added via form autofill are managed in about:preferences#privacy, under "Saved credit cards". This form is shared and has the same content as the form used to add/edit cards in the Web Payments UI. We will add a new field to this form, to track the type (network) of the card. The new field (a select control) will be visible in both preferences and payments UIs. * We will populate the card type picker with the list from [1], with an empty initial option for other or undefined. * The labels for the picker options (card networks) will be localized strings; the values the network-ids. * The new field will be named "cc-type" to align with the whatwg guidelines on form autofill/autocomplete [2] In the payment request context "type" is typically used to mean one of "credit", "debit" or "prepaid", and the card networks (which correspond to the familiar brands like Visa, Mastercard etc) are consistently referred as "networks". So we'll need to be on guard for confusion there. 1. https://www.w3.org/Payments/card-network-ids 2. https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#attr-fe-autocomplete-cc-type
* Add cc-type as a valid field for credit card forms * Add a select menu and new string for designating a card type in the add/edit form * Enforce matching of cc-type to one of the list of supported network ids for Basic Card * Expose the network ids list as CreditCard.SUPPORTED_TYPES * Populate the cc-type options using a getCreditCardTypes util method passed into the EditCreditCard constructor * WIP: Web Payment tests: verify cc-type picker is presented, populated as expected and selections received in the response MozReview-Commit-ID: 9QyU1UwTRay
Comment on attachment 9002588 [details] Bug 1477105 - Support cc-type as valid field for credit cards in form autofill. r?MattN Matthew N. [:MattN] (PM if requests are blocking you) has approved the revision.
Attachment #9002588 - Flags: review+
Pushed by mozilla@noorenberghe.ca: https://hg.mozilla.org/integration/mozilla-inbound/rev/1f763bb7c0ef Support cc-type as valid field for credit cards in form autofill. r=MattN
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 63
Hi Sam, I'm verifying the fix on the latest Nightly 63.0a1 (2018-08-31) on Windows 7/10, Ubuntu 16.04, Mac OS 10.13. Regarding the first 3 fixes: * Add cc-type as a valid field for credit card forms * Add a select menu and new string for designating a card type in the add/edit form * Enforce matching of cc-type to one of the list of supported network ids for Basic Card Verified - Fixed: on all mentioned OS there is a CC-type field on the credit card Add/Edit form with a drop-down menu that has 9 supported networks as enlisted in https://www.w3.org/Payments/card-network-ids. Is there something else that I missed and should've checked? Regarding the last 2 fixes: * Expose the network ids list as CreditCard.SUPPORTED_TYPES * Populate the cc-type options using a getCreditCardTypes util method passed into the EditCreditCard constructor I do not know how should I verify these or if it can be verified by manual testing at all. Can you please guide me here?
Flags: needinfo?(sfoster)
> Regarding the last 2 fixes: > * Expose the network ids list as CreditCard.SUPPORTED_TYPES > * Populate the cc-type options using a getCreditCardTypes util method passed > into the EditCreditCard constructor > > I do not know how should I verify these or if it can be verified by manual > testing at all. Can you please guide me here? Yeah those are implementation details. If the drop-down in the add/edit forms in both the payment dialog and the preferences UI are populated with the expected networks that is good. It would also be good to test the form autofill cases. The network dropdown (cc-type) is not as widely adopted (as cc-number etc.) Filling in a credit card form on a web page that includes a cc-type field should capture that value along with other data. Auto-fill should select the appropriate network in a credit card form with the cc-type name. I've been using a test page on my dev box for this. I don't see the cc-type dropdown on the form autofill test pages I've found out on the web. Do you know of a good (public) resource for this? If we (mozilla) maintain some test pages I could update them to include the network dropdown.
Flags: needinfo?(sfoster) → needinfo?(timea.babos)
I found one test page which may be good for testing autofill cases. On the https://luke-chang.github.io/autofill-demo/basic_cc.html test-page, I replaced the autocomplete for CSC with autocomplete="cc-type". After I selected one saved name with autofill all the fields were populated accordingly, including the Credit Card type (network). Tested it for all supported network types and it worked. Please tell me if this is an eligible check for autofill cases or not, here is a screenshot of how it looks: https://imgur.com/fkMb92j
Flags: needinfo?(timea.babos) → needinfo?(sfoster)
Creative! Yes, that is a good verification. Thanks.
Flags: needinfo?(sfoster)
Thanks Sam! Based on Comment 10 and Comment 12 I will mark this issue as Verified - Fixed on all OS on Nightly 63.0a1 (2018-08-31) and latest 64.0a1 (2018-09-04)
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: