Open Bug 1753710 Opened 3 years ago Updated 2 years ago

Clear form address dropdown option is not displayed on several sites

Categories

(Toolkit :: Form Autofill, defect, P3)

Desktop
All
defect

Tracking

()

Tracking Status
firefox96 --- affected
firefox97 --- affected
firefox98 --- affected

People

(Reporter: ailea, Unassigned)

References

(Blocks 2 open bugs, )

Details

Attachments

(1 file)

Attached video 2022-02-04_19h19_34.mp4

Affected Versions:

Nightly 98.a1, Beta 97 and Release 96

Tested on:

MacOS 11
Windows 10

Preconditions:

browser.search.region CA
extensions.formautofill.addresses.enabled - true
extensions.formautofill.supportedCountries US,CA
download latest Firefox Nightly with region locale
have a complete address already saved in about:preferences#privacy

Steps to reproduce:

  1. Reach the address form on etsy.ca
  2. Using the autofill feature, select any saved address entry.
  3. Click in any autofilled field in order to open the address autofill dropown.

Expected Results:

The Clear Form option is displayed in the autofill dropdown and it works as expected.

Actual Results:

The Clear Form option is not displayed a tall in the autofill dropdown.

Notes:

Reproducible on Chrome: No.

Since there are multiple sites with the same issue, we will track all those sites in this bug and we can separate them if needed.
Websites with this issue known until now: etsy.ca, homedepot.ca, thebay.com, walmart.ca, vinted.fr

For the Etsy case, it looks like the code is not successfully detecting a previously filled form. For example, I'm able to autofill from the email field and see the "Clear Form" option from each input. If I autofill from name, street address, etc then form autofill behaves as if these fields weren't autofilled already as we can see in the video in Comment #0. Etsy also overwrites our autofill styling, making visual comparison more difficult. From what I'm seeing, we seem to autofill correctly then the highlight disappears off the Zip code/postal code field after filling, which resets (or sets) the zip/postal code field's state to "normal" which means you can autofill again using that particular field. I'm still not sure why the field's state is resetting.

It seems like the zip code field is the issue, as I can infinitely autofill from this field. I'll have to spend some more time later looking at this issue. Hopefully the other sites aren't having this same behavior...

For the Home Depot case, we have a very similar result as the Etsy case. Autofill works correctly, but appears to flip an already autofilled field back to the "normal" state when double-clicking into that field instead of showing the clear form option. It seems that getFormInfo is getting called again after autofill has occurred, which probably shouldn't be happening. Something is calling _doIdentifyAutofillFields after autofilling, but it appears to be coming from a callback in Timer.jsm so I'm not sure what is really calling _doIdentifyAutofillFields. According to this search, it's most likely the "focus in" event that is calling the identify autofill fields function. I'm not sure why the form is resetting in this case but not in a case like our basic address autocomplete test page.

Okay, I think I figured out the Home Depot case. So we show the autocomplete dropdown as expected and fill as expected. Then, once we fill, the website adds these "clear field" buttons for each filled input. These newly generated clear buttons live inside the form and so the next time we call identifyAutofillFields, we end up calling the updateFormIfNeeded function. Eventually in this function, we check if the current form has a different number of elements than the stored form. The original, or stored, form didn't have these clear buttons associated with it, but the current form does so we end up updating the stored form. By calling _updateForm we reset the field details, sections, and _sectionCache associated with the form. Since we now have a blank form essentially, the next time a user interacts with the form, the form will be in a "reset" state since this form appears to be a new form to us due to the clear buttons being added. No idea how to avoid this situation off the top of my head though.

For thebay's case, it's similar to the Home Depot case. There's an additional element that is added to the form after autofilling and so we update our stored form which means we essentially reset the stored state of the filled fields so they have the "normal" state when clicking on them after filling. For some reason, there's a field that gets duplicated, "shipmentUUID" after autofilling. Like it already exists in the form before filling but it gets duplicated and added for some reason...then this duplicated field seems to be removed the next time you click on an input that wasn't originally used for the autofill. I guess a fix for the Home Depot case will also fix this case since they both seem to be cases where elements are added or removed after filling a form.

For the Walmart case, it appears identical to the Home Depot case in Comment #2. There are "clear field" buttons being added after autofill. Since these buttons didn't exist originally, we end up calling _updateForm and resetting the form. Since the form was reset, all the previously filled fields are in the "normal" state and can be autofilled again.

For the Vinted case, it appears identical to the Home Depot case in Comment #2. When autofilling the information, once the ZIP or postal code equivalent is filled in, a new field appears. This new field is the town/city which is not originally present when we determined the field details of this form. Since there is a different number of elements of our stored form versus the current one, we reset our details and update the form. Since the form has been updated, it now appears to be a new form which allows autofill to occur again (and prevents the clear form drop down from appearing).

Priority: -- → P3
Depends on: 1755694
Depends on: 1755927
See Also: → 1776882

Same issue is reproduceable on https://www.etsy.com/ while using US VPN.
This was tested using the latest Nightly 113.0a1 version on macOS 13.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: