* Flip the component pref to true by default for nightly builds only
* Move the pref check and initialization to a startup idle task
* And be a bit smarter about when we get and disable the addon
* Fix a bug where we try to communicate with the overlay after the window actor is destroyed when
the component pref gets flipped off during use
Differential Revision: https://phabricator.services.mozilla.com/D196888
* Flip the component pref to true by default for nightly builds only
* Move the pref check and initialization to a startup idle task
* And be a bit smarter about when we get and disable the addon
* Fix a bug where we try to communicate with the overlay after the window actor is destroyed when
the component pref gets flipped off during use
Differential Revision: https://phabricator.services.mozilla.com/D196888
* Flip the component pref to true by default for nightly builds only
* Move the pref check and initialization to a startup idle task
* And be a bit smarter about when we get and disable the addon
* Fix a bug where we try to communicate with the overlay after the window actor is destroyed when
the component pref gets flipped off during use
Differential Revision: https://phabricator.services.mozilla.com/D196888
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
When content analysis is on, pastes will be checked by the CA
agent while tab input is blocked. The synchronous nsIClipboard.getData()
method must block until the analysis result is received, so this
requires doing a SpinEventLoopUntil.
Differential Revision: https://phabricator.services.mozilla.com/D196997
Merge the First Name, Middle Name, and Last Name fields in the address management
dialog into a single `Name` field, similar to what we currently have in the edit
address doorhanger.
The reason for this change is not just to synchronize the design.
The main motivation is that a single name field allows users to enter names with
more information, for example, Mr. John Doe. Since first name + middle name + last name
is a subset of name ,we should not limit what users can enter from the outset.
Differential Revision: https://phabricator.services.mozilla.com/D196066
