1780775 - Weird behaviour for autofill addresses on amazon

Status: NEW

(Toolkit :: Form Autofill, defect, P3)

Description

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Attachment: broken

Found in

• Nightly 104.0a1

Affected versions

• Nightly 104.0a1
• Firefox 102.0
• Firefox RC 103.0
• Firefox 102.1esr

Affected platforms

• Windows 7
• Windows 10

Preconditions

• browser.search.region to US
• Have a saved adress in about:preferences#privacy.

Steps to reproduce

1. Launch Firefox and go to https://www.amazon.com/.
2. Log in using a valid account.
3. Click on Account and select "Your Addresses".
4. Click on Add Address.

Expected result

• The autofill works properly, address is saved and displayed.

Actual result

• The country is changed and the input is lost.

Regression range

• Will look for one ASAP.

Additional notes

• Please check the video for more detail.

Comment 1

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

mozregression points to:

• last good: 2022-05-13

• first bad: 2022-05-14

• pushlog:
  https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a04e5744fe2efb05261ff23180a1ff6388e2e5ff&tochange=4459dc0bd90d9a7e1b97e76e40a644f3b26e7f27

Please feel free to change if you think this isn't the correct regressor.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1754879

:tgiles, since you are the author of the regressor, bug 1754879, could you take a look?
For more information, please visit auto_nag documentation.

Comment 3

[Sergey Galich [:serg]]

Ardelean Oana, this looks like the web site's own mechanics to clear address fields when country is changed.

I've tried with "Autofill addresses" setting off, entered some data, then switched country and all my inputs was cleared.

Lets update STR to more details after step 4. By looking at attached video I can't tell where things start to go wrong.

Comment 4

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Hy Sergey!

My apologies for any lack of clarity in the STR.

Before, Amazon's autofill was not working on some platforms (that's bug 1692864). Autofill seems to be slightly more functional now, but once you auto-fill credentials in the Address Form on amazon.com, the country changes without any other input from the user.

I re-tested on Firefox 105.0b4 and a 2022-08-28 Nightly build and it's still reproducible on Windows 10 and macOS 12. The bug does not reproduce anymore on Ubuntu 22.04, wayland/X11 protocols.

I could consistently reproduce on affected builds and platforms with these STR (they will work with a previously saved address in about:preferences#privacy. Please use United States as the country of choice, on both Saved Addresses and Amazon).

1. Launch Firefox and go to https://www.amazon.com/.
2. Log in using a valid account.
3. Click on Account and select "Your Addresses".
4. Click on Add Address.
5. Click on any field and choose a saved Address from your Saved Addresses to autofill.

Expected:

• Would be to autofill the form properly.

Actual:

• The form IS autofilled, but the Country field is changed without the user's input after a second. In most testing scenarios it defaults to Canada.

I attached a recording of autofill's behaviour on Ubuntu and a recording on macOS. Both scenarios were tested on the latest Nightly. Please let me know if there's anything else I can do to help.

Comment 5

[Sergey Galich [:serg]]

(In reply to Ardelean Oana from comment #4)

... it's still reproducible on Windows 10 and macOS 12. The bug does not reproduce anymore on Ubuntu 22.04, wayland/X11 protocols.

Hmm, this is interesting. I don't see why would OS matter in this case. :issammani can you take a look please?

Comment 6

[Issam Mani [:issammani]]

:serg I will look into it !

Comment 7

[Issam Mani [:issammani]]

:serg :Ardelean Oana I was able to reproduce the bug on nightly 106.0a1 only.

After further investigation and testing with multiple addresses it seems that the country field is updated with the value of the state from the saved address. Assuming that the auto-filled address in the recording has California (CA) for a state, this explains why you would get Canada. I played around with different states and I get different results depending on the state code. I will investigate further and see why the heuristic misidentifies the country field.

Comment 8

[Issam Mani [:issammani]]

This seems to be a problem with the way we classify an address element ( input, select ). In _findMatchedFieldName we loop through all regex rules for different address parts ( country, state, address-level-*) and then return when an element's identifiers ( id, name, label ) matches the current rule.

The problem is we return the moment an identifier matches a rule.

In amazon's case the country select has the following identifiers:

label: Country/Region
id: address-ui-widgets-countryCode-dropdown-nativeId
name:  address-ui-widgets-countryCode

Since we loop over the regex first and try to match we end up matching the label: Country / Region to address-level1 regex for address-level1 macthes the region part, which is wrong. It will cause the select to be updated with the value stored for address-level1 ( state ) instead of country.

We can switch the order of the loops, so we prioritize id and name before label, or order the regex rules differently, so as to prioritize country, but we will still encounter the same problem as before in some other edge case. A simple solution would be to match all the descriptors and see the most frequent one. In the case of amazon that would be country since:

Country/Region will match address-level-1
address-ui-widgets-countryCode-dropdown-nativeId will match country
address-ui-widgets-countryCode will match country

This would be a start to improve the matching, but we will still need to handle some other edge cases ( same frequencies ... ).
:serg :dimi what do you think about this ?

Comment 9

[Dimi Lee [:dimi]]

HI Issam, sorry for the late reply!
The solution you suggested has the same idea as fathom - Using multiple rules to determine the result. However, I would be careful about adding this kind of heuristic because very often in the end we solve one issue in a site, but create a new one in another site.

Since in this case the misclassified element is a <select> and it contains <option>s with Country Name, do you think we can use this as a hint to recognize country?

Comment 10

[Issam Mani [:issammani]]

Attachment: Bug 1780775 - Add test to reproduce bug and catch it. r=sgalich!

Comment 11

[Issam Mani [:issammani]]

Attachment: Bug 1780775 - Add _isCountryLikely function to match country selects. r=sgalich!

Depends on D160167