1730016 - [meta] Redesign how we search for credit card fields in forms

Status: NEW

(Toolkit :: Form Autofill, enhancement)

Description

[Tim Giles [:tgiles]]

Due to certain patterns on the web, our current "searching for fields" process will not work as expected. This could be due to a myriad of reasons:

1. Form has duplicate credit card fields, some of which are visibly hidden.
   Our current logic will determine that these hidden fields are the fields we should be filling into. If the website doesn't have some kind of sync between hidden and visible fields, then we aren't helping people get through the payment process. See Bug 1684938, Bug 1688576 and Bug 1727701 as examples.

Calculating visibility of a field can be a very expensive operation, and so solving this will result in compromises between completeness and performance. See Bug 1247245 for more thoughts on this process, specifically Comment #6.

2. There are nested forms/nested iframes on a payment page.
   Our current logic will find the nearest form ancestor for an element in order to determine what fields should be considered a "credit card section" (and address section, to be clear). Since the nearest form isn't the "root" form in these cases, we will fail to successfully determine credit card sections and not help people get through the payment process.

Additionally in this case, this nested form will break our other logic and potentially prevent the other credit card fields from being considered valid. In Bug 1682161, the nested form has the cc-number field as a child element. This prevents the cc-number field from being considered as part of the "other" credit card section, but will also prevent any other credit card section from being valid! This is because of the "isValidSection()" check needing a cc-number field in order to be valid.

3. A field has an ID that contains text that better matches address or other credit card field type.
   In Bug 1682161, there are two fields that have IDs that contain "Ecom_BillTo_Postal_Name_". In the current logic, we parse phone fields, then address fields, then credit card fields. When we parse phone fields, we also try to find matches for the field name if the field doesn't already have an autocomplete attribute. Unfortunately, in the current order, we check for postal codes before cc-name fields. Due to this, we end up matching these name fields as postal code fields and not name fields!

4. The credit card number field is split into four separate sections.
   Our current logic will not handle duplicate credit card number fields and prevent the autocomplete popup from appearing from all but the last one (as long as there are other valid cc fields following the last cc-number field). See Bug 1688607 for an example. We will need a way to determine if there are multiple cc-number fields and aggregate them into the credit card section, as well as change the filling logic so that each cc-number field receives the correct four digits of the credit card.