This patch adds two telemetry to measure the performance impact after adding
multi-page login support.
Telemtry PWMGR_IS_USERNAME_ONLY_FORM gives us an idea among
all forms that contain a possible username input (type is email or text), the propotion
of those forms that are considered as a username-only form by our heuristic. We can
use this data as a hint of whether the username-only form heuristic works properly.
Telemetry PWMGR_NUM_FORM_HAS_POSSIBLE_USERNAME_EVENT_PER_DOC gives us an
idea how many forms contain a possible username input per page. If the data shows that there are a
lot of pages that contain multiple forms with a possible username input, which
triggers the new code path added in this bug, we might need to pay more attention to see whether the
change introduces performance overhead for page load.
Ex. A doc has 4 forms
<form><input type=email autocomplete=username/></form> <!-- This is a form with a possible username input, and it is a username-only form-->
<form><input type=text autocomplete=username/></form> <!-- This is a form with a possible username input, and it is a username-only form-->
<form><input type=email/></form> <!-- This is a form with a possible username input, but it is NOT a username-onlyc form -->
<form><input type=urk/></form> <!-- This is a form WITHOUT a possible username input -->
PWMGR_IS_USERNAME_ONLY_FORM records
bucket[0] = 1 // 1 form with a possible username input but not a username-only form
bucket[1] = 2 // 2 forms are username-only form.
PWMGR_NUM_FORM_HAS_POSSIBLE_USERNAME_EVENT_PER_DOC records
bucket[0] = 0
bucket[1] = 1 // 1 doc has 1 or more than 1 form with a possible-username input
bucket[2] = 1 // 1 doc has 2 or more than 2 form with a possible-username input
bucket[3] = 1 // 1 doc has 3 or more than 3 form with a possible-username input
bucket[4] = 0 // 0 doc has 4 or more than 4 form with a possible-username input
Depends on D113802
Differential Revision: https://phabricator.services.mozilla.com/D116237
This patch saves the username field in a username-only form when the form is submitted.
When another form in the same document is submitted after that, if the form doesn't
have a username field, we then use the username field found in the username-only form to capture login.
This fits the case that in a multipage sign-in form, the first form is
usually a username-only form and the second form is usually a password-only form.
However, in the current approach, if in the second form, there is an input field before the
password field, we will use the input field in the second form as the username field, not the username field
in the first form. For example, in a multipage registration form, the first form is a username-only form to
enter your email, and the second form has an input field to enter the last name and a password field. With the
current approach, we will save "last name" + "password" instead of "username" + "password".
An alternate is always using the username field in the first form or coming up with a heuristic
to "compare" the two username fields. But since I haven't found a real-world example of the above scenario,
using the current approach seems a safer way to introduce the feature.
Depends on D113800
Differential Revision: https://phabricator.services.mozilla.com/D113801
In the previous patch to support autofill, a username field in a
username-only form is marked as a login manager field in '_fillForm'.
So this patch only makes autocomplete highlight work when autocomplete a username field.
This patch calls '_highlightFilledField' in 'onUsernameAutoCompleted'
when the autocompleted field is the username field in a username-only
form.
This is because when we autocomplete a username field in a form with password fields,
the highlight is done in '_fillForm'. However, in the case of a username-only
form, we don't have to call '_fillForm' anymore due to no password to fill.
Depends on D113799
Differential Revision: https://phabricator.services.mozilla.com/D113800
This patch does two things:
1. Checks whether a form is a username-only form after receiving 'DOMFormHasPossibleUsername' event.
If it is, fetch logins from the parent to trigger form autofill.
2. Makes LoginManagerChild._fillForm compatible with an empty password field when there is an username field.
Depends on D113798
Differential Revision: https://phabricator.services.mozilla.com/D113799
Right now, we limit the type of a username field in username-only forms to be either text or email.
This is different from what the password manager currently support in LoginHelper.isUsernameFieldType.
This is because text and email type are the most common cases for a username field, and we want to focus
on the cases that are more likely a username field.
This patch adds "DOMFormHasPossibleUsername" event to notify the password manager when a form has a possible
username field (text or email). The event works similar to the existing "DOMFormHasPassword" event.
Depends on D113797
Differential Revision: https://phabricator.services.mozilla.com/D113798
Before the patch, we don't show password manager items when there is no password fields found in a form.
In this patch, we do two things to support a username-only form in the context menu:
1. Add "other" category to fieldname hints. "other" is used for fields that are
in a form but are neither "current-password", "new-password", nor "username".
With the change, the "username" hint is now only used for fields that are considered a username field by the password manager.
2. When there is no password field in a form, ContextMenu also treat a
form as a login form when the active field is a username field, which means it is a username-only form.
Depends on D113796
Differential Revision: https://phabricator.services.mozilla.com/D113797
Before this patch, '_getFormFields' doesn't support forms without password fields.
In this patch, when a form doesn't have a password field, we use the
heuristic added in the previous patch to determine whether the form is a
username-only form. If it is, return the username field.
Depends on D113795
Differential Revision: https://phabricator.services.mozilla.com/D113796
This patch adds a histogram to keep track of the number of passwords generated via custom rules and default rules when "signon.improvedPasswordRules.enabled" is true.
This way, we can see if there is actual use of this feature for future decisions.
Differential Revision: https://phabricator.services.mozilla.com/D116870
This patch will allow us to generate passwords based on rules and domains.
This patch also implements special characters needed to generated these new passwords.
However, this does not change the previous password generator behavior regarding special characters.
If a particular domain does not have a set of password rules associated with it, then we will generate a password with no special characters.
Differential Revision: https://phabricator.services.mozilla.com/D114111
The improvements include:
* Add translated keywords
* Add a formHasMultipleVisibleInput signal.
This rule returns true when there is more than 3 visible input in a form.
Since the idea in the signal is that a registration page often has multiple inputs.
This rule only selects inputs whose type is either email, password, text, tel or empty,
which are more likely a input field for users to fill their information.
* Support formless password field in formHasMultipleVisibleInput signal.
For password fields don't have an associated form, signals that require a form always return false.
This patch adds an additional heuristic in formHasMultipleVisibleInput signal to support formless
password field. The heuristic works as follow:
1. Locate the closest preceding input with selector
"input[type=email],input[type=text],,input[type=tel],input[type=password]".
2. Find the lowest common ancestor of the password field and the input field found in step1
3. Use the common ancestor as the "form" element, apply `formHasMultipleVisibleInput` signal
* Add a firstFieldInFormWithThreePasswordFields signal
The signal is based on that change-password forms with 3 password fields
often have the "current password", "new password", and "confirm password" pattern.
Differential Revision: https://phabricator.services.mozilla.com/D111926
The improvements include:
* Add three french keywords
- Add Créer to newStringRegex
- Add S'inscrire to registerStringRegex
- Add Créer un compte to registerStringRegex
* Add a formHasMultipleVisibleInput signal.
This rule returns true when there is more than 3 visible input in a form.
Since the idea in the signal is that a registration page often has multiple inputs.
This rule only selects inputs whose type is either email, password, text, tel or empty,
which are more likely a input field for users to fill their information.
* Support formless password field in formHasMultipleVisibleInput signal.
For password fields don't have an associated form, signals that require a form always return false.
This patch adds an additional heuristic in formHasMultipleVisibleInput signal to support formless
password field. The heuristic works as follow:
1. Locate the closest preceding input with selector
"input[type=email],input[type=text],,input[type=tel],input[type=password]".
2. Find the lowest common ancestor of the password field and the input field found in step1
3. Use the common ancestor as the "form" element, apply `formHasMultipleVisibleInput` signal
Differential Revision: https://phabricator.services.mozilla.com/D111926
The username searching heuristic locates a username like or an email like field
by:
1. Checking if the input field's type is 'email'.
2. Checking if the input field's autocomplete attribute is 'username' or 'email'
3. Searching 'username' and 'email' keyword in:
- The input field's "id", "name", "classname", and "placeholder" attributes.
- The input field's associate label
If any of the above rule matches, we consider the field a username or an
email field depending on the keyword that matches.
When both a username-like and an email-like field are found in a form, select
the username-like field as the final username field. If no field is
found by the above heuristic, assume the first field before the first
password is the username (This is how it works before the patch).
Note. Right now, even with the new heuristic, we still only search fields
preecede the first password field like what we did before. This is because
from the sites I have tested (~250 sites), all the username fields
precede the first password field. If it turns out this is not true for
some sites, we can consider searching all the input fields in the form.
Differential Revision: https://phabricator.services.mozilla.com/D110469
