Affected Versions:

Nightly 102a1, Beta 101 and Release 100

Tested on:

Windows 10

Preconditions:

browser.search.region US or CA
Have at least one already saved address in about:preferences

Steps to reproduce:

1. Reach ebay.ca, "buy" something and choose to sign in with google (use an gmail account that doesn't have an ebay account associated).
2. Using the autofill feature, select 1 saved address entry.

Expected Results:

All the fields should be successfully auto-filled.

Actual Results:

The province, postal code and the mobile number fields are not autofilled.

Notes:

Severity: S3 severity.
Reproducible on Chrome: No, all the fields are properly autofilled in Chrome.

I'll look into this and see what's going on.

Okay so the issue seems to be in identifying the fields correctly. Like getFormInfo has no issue seeing that all of the fields on this page are eligible fields, but they seem to be getting filter out during FormAutofillHeuristics._classifySections call and maybe again in the FormAutofillHeuristics.getSectionFieldDetails call. It seems there might be some hidden fields that are getting identified because during the part where we create sections based on the eligible fields (_classifySections), we end up creating two different sections. I think this is because going into _classifySections we have this data for fieldDetails:

Array(7) [ {…}, {…}, {…}, {…}, {…}, {…}, {…} ]
0: Object { section: "", addressType: "", fieldName: "address-level1", … }
1: Object { section: "", addressType: "", fieldName: "street-address", … }
2: Object { section: "", addressType: "", fieldName: "address-line2", … }
3: Object { section: "", addressType: "", fieldName: "address-level2", … }
4: Object { section: "", addressType: "", fieldName: "address-level1", … }
5: Object { section: "", addressType: "", fieldName: "postal-code", … }
6: Object { section: "", addressType: "", fieldName: "tel", … }

where it looks like the Country dropdown selector is being incorrectly identified as "address-level1" for some reason. Like the string that causes this regex match is "country/region"...which makes no sense because there are no "country" strings in the "address-level1" heuristic. Debugging right when this match occurs, I'm seeing a really odd result for this.RULES[regexp]. So regexp is "address-level1" which is odd, but when I look at the constructed regex for this rule, it seems like it has some incorrect regex strings in it:

/(land)|
((^state$)|
(^province$)|
(^provence$)|
(^address-?level-?1$)|
(^address-?state$)|
(^address-?province$))|
((?<!(united|hist|history).?)state|
county|
region|
province|
county|
principality|
都道府県|
estado|
provincia|
область|
省|地區|
സംസ്ഥാനം|استان|
राज्य|
((\b|_|\*)(eyalet|[şs]ehir|[i̇ii̇]l(imiz)?|kent)(\b|_|\*))|
^시[·・]?도)/u

I have no idea why the "country" regex strings are present here in the "address-level1" regex, but that seems to be the source of the issue.

Tested again in Beta 103.0b1 and the latest Nightly 104.0a1 and the following behavior is present now: Province, zip code and phone number fields are still not autofiled, but they successfully trigger the autofill dropdown and can be autofilled by selecting a value from their dropdown. Somehow those 3 fields seems to be separate from the others.