We introduced visibility/focusability check to filter out invisible or unfocusable elements
to address the following issues:
1. Bug 1688209: The website's credit card form contains hidden credit card fields beneath the visible ones.
Example:
<input id="cc-number" autocomplete="cc-number">
<input id="hidden-cc-number" autocomplete="cc-number" hidden>.
<input id="cc-name" autocomplete="cc-name">
The issue occurs because when our heuristic encounters consecutive fields that should not appear multiple times in a row,
we divide them and treat them as separate sections. In this example, the
visible cc-number and visible cc-name are put in different sections so we don't autofill both of the fields at the same time.
2. Bug 1822494: There is one hidden cc-exp-month field and one visible cc-exp field.
Example:
<input id="cc-exp" autocomplete="cc-exp">
<input id="hidden-cc-exp" autocomplete="cc-exp" hidden>.
When two cc-exp-* fields appear consecutively, our heuristic adjusts the first one to cc-exp-month and the second one to cc-exp-year.
However, in this bug, we should just honor the autocomplete attribute and do not change the field name
Bug 1753669: An invisible country field is located between tel-* fields.
Example:
<input id="country" autocomplete="country">
<input id="tel-area-code" autocomplete="tel-area-code">
<input id="hidden-country" autocomplete="country" hidden>
<input id="tel-local" autocomplete="tel-local">
When the heuristic sees the hidden country field, since it has already identified another country field previously,
our heuristic creates a new section upon encountering the invisible country field. This results that
we don't put tel-local field in the same section as the rest of the address fields.
---
However, introducing visibility and focusability checks also brings issues.
Some websites implement their own dropdowns for certain fields, like province, and include an invisible or unfocusable
field to store the value, as seen in Bug 1873202 and Bug 1836036.
We also see, in some cases, websites prefill certain address fields for users, and those fields are unfocusable.
For example, websites can use known-address data to determine the "state/province" field so users don't have to fill it.
But in these cases, we still want to identify this type of field so we can capture the data after users submit the form.
So, given the information collected so far, I think we should not filter out unfocusable or invisible elements before
running heuristics. Instead, we should adjust our heuristic to consider invisible elements in some cases. For example,
we should not create a new section upon encountering an invisible field, recognizing that it's common for websites to
place an invisible field near a visible field of the same type for various reasons.
Differential Revision: https://phabricator.services.mozilla.com/D202297
An explanation of the Firefox Source Code Directory Structure and links to
project pages with documentation can be found at:
https://firefox-source-docs.mozilla.org/contributing/directory_structure.html
For information on how to build Firefox from the source code and create the patch see:
https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html
If you have a question about developing Firefox, and can't find the solution
on https://firefox-source-docs.mozilla.org/, you can try asking your question on Matrix at chat.mozilla.org in `Introduction` (https://chat.mozilla.org/#/room/#introduction:mozilla.org) channel.
Nightly development builds can be downloaded from:
https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/
- or -
https://www.mozilla.org/firefox/channel/desktop/#nightly
Keep in mind that nightly builds, which are used by Firefox developers for
testing, may be buggy.
6cabc3f465