Closed Bug 1754739 Opened 3 years ago Closed 2 months ago

[FR][darty.fr] The autofill is no longer working after using the clear form option

Categories

(Toolkit :: Form Autofill, defect, P3)

Desktop
All
defect

Tracking

()

VERIFIED FIXED
Tracking Status
firefox97 --- disabled
firefox98 --- disabled
firefox99 --- disabled

People

(Reporter: ailea, Unassigned)

References

(Blocks 2 open bugs, )

Details

Attachments

(1 file)

Attached video darty.mp4

Affected Versions:

Nightly 99.a1, Beta 98 and Release 97

Tested on:

MacOS 11
Windows 10

Preconditions:

browser.search.region FR
extensions.formautofill.addresses.enabled - true
extensions.formautofill.addresses.supported to "detect"
extensions.formautofill.addresses.supportedCountries US,CA,FR
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 darty.fr
  2. Using the autofill feature, select 1 saved address entry.
  3. Click on any autofilled field and choose the clear form option.
  4. Using the autofill feature, select 1 saved address entry on any field.

Expected Results:

The autofill should work accordingly after using the clear form option.

Actual Results:

The autofill is no longer working after using the clear form option.

Notes:

Reproducible on Chrome: The autofill is not working at all on Chrome, on darty.fr

Flags: needinfo?(tgiles)

Alright, this one is a bit odd. So the bug seems to live in the startSearch function of AutofillProfileAutoCompleteSearch. So the form has been populated previously and the field is not an empty credit card field since I happen to be clicking on the Prenom field. Because of this we fallback to form history and don't show the address autofill dropdown as expected. Thinking more about it, I guess there's a bug in the clearing of the form then. If we successfully clear a form then it shouldn't have any kind of populated state associated with it...

Okay, think I have a better idea of what's going on. So there are two disabled inputs on this page, Ville/City and Adresse/Address. These inputs are disabled until the user fills the code postal field. When filling, all works as expected but when clearing we end up clearing the Code postal field before Ville or Adresse. This causes these two fields to become disabled again, which shouldn't be an issue. The Ville field happens to clear correctly as we see in the video in Comment #0, but the Adresse field doesn't seem to clear correctly and maintains its autofilled state even though the value has been cleared. Since this field visually appears to be autofilled, I have a hunch that our internals also believe the form is still in a populated state thus we don't get the address autocomplete after clearing the form.

Weird, it tends to appear that when we reset the values for inputs using setUserInput(""), we also end up calling _changeFieldState in FormAutofillHandler. Our code knows the address field that is not behaving correctly is part of the form and everything, it consistently shows up in the fieldDetails in these various functions, but this one field doesn't seem to trip the _changeFieldState function. Oh, okay I think I got it.

Since the Adresse field is disabled, when we set user input via setUserInput I bet we aren't sending an "input" event on this change, because it's a disabled field at this point. Since we're not sending an input event, we never have a chance to call this._changeFieldState(targetFieldDetail, FIELD_STATES.NORMAL) and reset this address field. And since we don't reset this field, our code thinks we shouldn't show any address autocomplete results, just form history results.

We shouldn't change setUserInput to send events in this particular case, so I guess the fix is figuring out how to call _changeFieldState inside of clearPopulatedForm I suppose.

Flags: needinfo?(tgiles)
Priority: -- → P3

This appears to be working now. Based on the comment above, this looks like it was just an instance of bug 1849122.

Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED

Verified - Fixed in Release 128, Beta 129.0b3 and Nightly 130.0a1 (2024-07-15). As for bug 1849122, the issue described is no longer reproducible.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: