It turns out that many sites are modifying the field state immediately after a value has been autofilled, typically to format the value such as add spaces between parts of a credit card number
Differential Revision: https://phabricator.services.mozilla.com/D215113
The enrollmentHelper was much more complicated than it needed to be. The
internal asynchrony that required awaiting an additional promise was fixed in
bug 1773583.
The returned cleanup function is no longer async, so unnecessary awaits have
been removed. This also applies to enrollWithFeatureConfig, as it is a wrapper
around enrollmentHelper.
Differential Revision: https://phabricator.services.mozilla.com/D212318
***
Bug 1898323 - follow-up: fix tests now that beta/release default to not enabling CC/pwd autofill os reauth
***
Bug 1898323 - fix about:logins and formautofill tests better given the disabling of OS reauth on beta/release
***
Bug 1898323 - Fix OsAuth migration for beta and have it disabled by default on Beta and Release. r=ssachdev!,issammani!
***
Bug 1899368 - Disable OS Auth for new users in Beta and Release. r=issammani!,gijs!
***
Aligned anti_clickjacking with beta
Differential Revision: https://phabricator.services.mozilla.com/D212577
The existing autofill state is set on the form element using nsIDOMWindowUtils::AddManuallyManagedState, but a separate map #filledStateByElement within FormAutofillHandler.sys.mjs is used to keep track of which elements are filled in. However, this relies on input events that don't fire when form elements are hidden. In addition, when a page modifies the form field value directly, the preview state can be modified but the #filledStateByElement map is not.
Instead, remove the extra map, and just use the form field's autofill state directly. The form field will take responsibility for removing the preview state when its value changes.
This behaviour applies to single field input elements and select elements.
Differential Revision: https://phabricator.services.mozilla.com/D211000
This patch adds the following messages to the autocomplete item:
1. For address and credit card autofill, use the `FormAutofill:FillForm` message.
2. For login autofill, use the `PasswordManager:OnFieldAutoComplete` message.
3. For generated password autofill, use the `PasswordManager:FillGeneratedPassword` message.
After adding the above three messages, every autocomplete item that performs an action
upon being clicked has a corresponding `fillMessageName`.
Here is how the new architecture works:
1. Whenever a user selects an autocomplete entry, the `AutoCompleteChild` sends
the `AutoComplete:SelectEntry` message to the parent process.
2. `AutoCompleteParent` extracts `fillMessageName` from the message and uses
the prefix of the message name to determine which actor should process this message.
3. The `OnFieldAutoCompleteEntrySelected` method of the actor is called. The actor in
the parent process determines what action to take.
Differential Revision: https://phabricator.services.mozilla.com/D209353
The Storage Access API now requires 3rd-party iframes to request storage access after load.
Storage access isn't granted automatically anymore, even if a previous storage access request
has been granted.
Differential Revision: https://phabricator.services.mozilla.com/D210713
We extract the renaming of this test file to a separate patch, because P3 modifies and adds test cases and we want to keep the diff (to simplify review of P3).
Differential Revision: https://phabricator.services.mozilla.com/D208133
FormHandler is a central place for heuristics that other components like the LoginManager and FormAutofill
rely on. This patch moves the heuristics that detect page navigations to the FormHandler.
It also applies two changes:
- Heuristic to capture on page navigation no longer relies on the process' active element in FormAutofill
- Capturing in cross-origin frames is introduced
Introduced page navigation heuristic:
When LoginManager/FormAutofill detect a form that they expect a submission for, a FormHandler actor pair is
created in the current window context, which registers the web progress listener that listens for "page navigations",
e.g. location changes of the observed window/document or history session changes.
- If the form is in a same-orign frame, we register the listener only at the top level.
- If the form is in a cross-origin frame, we additionally set up a listener with the root
of the cross-origin process, so that we are aware of page navigations in both processes.
When a page navigation is observed, all existing (same-origin and cross-origin) FormHandler parents in the
browsing context subtree notify their children.
(Note: We don't create any new actors in this step, because they won't have any form to submit anyway).
When the corresponding FormHandlerChild(ren) are notified of the page navigation, they fire the "form-submission-detected" event.
On "form-submission-detected" event:
- The LoginManagerChild instance(s) kept track of all modified login forms and infers capturing them.
- The FormAutofillChild instance(s) kept track of all identified formautofill forms and infers capturing them.
Differential Revision: https://phabricator.services.mozilla.com/D204927
We extract the renaming of this test file to a separate patch, because P3 modifies and adds test cases and we want to keep the diff (to simplify review of P3).
Differential Revision: https://phabricator.services.mozilla.com/D208133
FormHandler is a central place for heuristics that other components like the LoginManager and FormAutofill
rely on. This patch moves the heuristics that detect page navigations to the FormHandler.
It also applies two changes:
- Heuristic to capture on page navigation no longer relies on the process' active element in FormAutofill
- Capturing in cross-origin frames is introduced
Introduced page navigation heuristic:
When LoginManager/FormAutofill detect a form that they expect a submission for, a FormHandler actor pair is
created in the current window context, which registers the web progress listener that listens for "page navigations",
e.g. location changes of the observed window/document or history session changes.
- If the form is in a same-orign frame, we register the listener only at the top level.
- If the form is in a cross-origin frame, we additionally set up a listener with the root
of the cross-origin process, so that we are aware of page navigations in both processes.
When a page navigation is observed, all existing (same-origin and cross-origin) FormHandler parents in the
browsing context subtree notify their children.
(Note: We don't create any new actors in this step, because they won't have any form to submit anyway).
When the corresponding FormHandlerChild(ren) are notified of the page navigation, they fire the "form-submission-detected" event.
On "form-submission-detected" event:
- The LoginManagerChild instance(s) kept track of all modified login forms and infers capturing them.
- The FormAutofillChild instance(s) kept track of all identified formautofill forms and infers capturing them.
Differential Revision: https://phabricator.services.mozilla.com/D204927
