1951890 - [CA][saje.ca] The 'Save Address' doorhanger does not appear after the form is submitted

Status: VERIFIED FIXED

(Toolkit :: Form Autofill, defect, P2)

Description

[Alin Ilea, Desktop Test Engineering]

Attachment: inspect-www.saje.ca.png

Found in

• 138.0a1

Affected versions

• 138.0a1

Tested platform

• Windows 10

Preconditions

• Have set in about:config:
• browser.search.region - CA

Steps to reproduce

1. Go to https://saje.ca and reach the shipping address form.
2. Fill in manually new Address info and submit the form.

Expected result

• The "Save Address" doorhanger should appear after the form is submitted.

Actual result

• The "Save Address" doorhanger does not appear after the form is submitted.

Regression range

• Seems to be a regression from March 2nd, here is the pushlog found using mozregression: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2879c26ed4ccd7a9b005c95872bbf91bde6dc001&tochange=543c21c8e3522666952061bdfbeef2300733243d

Additional notes

• The address capture doorhanger IS displayed with the extensions.formautofill.addresses.capture.requiredFields set to empty.
• The address capture doorhanger IS displayed in Nightly 137 by default, without set the extensions.formautofill.addresses.capture.requiredFields to empty.
• By setting the following preferences to false, will still NOT trigger the capture doorhanger:
  extensions.formautofill.heuristics.detectDynamicFormChanges
  extensions.formautofill.heuristics.fillOnDynamicFormChanges
• Downloaded page.

Comment 1

[Dianna Smith [:diannaS]]

From my understanding it is working properly in 137, however the regression range is from 137. Alin, are you confident in the range? If so I dont see anything obvious in that range.

Comment 2

[Alin Ilea, Desktop Test Engineering]

Hi, I will try to get a new regression range as soon as possible. In the meantime, Janika is working on the bugs related to the dynamic form support implementation, like this one, so maybe she has an idea or she can investigate much closer this issue.
Thanks.

Comment 3

[Alin Ilea, Desktop Test Engineering]

Ok, I just found a new regression range for this issue that makes sense now: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=f426167fc251be278ac2768d7604a32e468d78cc&tochange=83edcec30c306aea714ebc02d90bc196646623ab
so the regressor, as expected, seems to be bug 1837161.

Comment 4

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

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

Comment 5

[Dianna Smith [:diannaS]]

janika, is it possible to set a priority/severity for this? Is this something we want to fix before shipping in 138?

Comment 6

[Janika Neuberger [:janika]]

Hi Dianna, I'm still unsure why and how this is regressed by Bug 1837161, but I'll debug further. But it's not critical if it doesn't get fixed in Fx138.

Comment 7

[Janika Neuberger [:janika]]

Ok, I got to the root cause of it.

After initial field detection a tel-country-code field is added to the form dynamically. It is misclassified as address-level1 field and overrides the other correctly detected address-level1 field when the record gets created for the form submission. But the tel-country-code value is not a valid address-level1 value, the address-level1 field gets discarded from the record. And since it is a required field, discarding it aborts showing the save address doorhanger.

We misclassify the field, because we currently only detect tel-country-code fields when they explicitly set autocomplete="tel-country-code", which the field on saje.ca does not. I filed Bug 1955655 in order to also support detecting tel-country-code fields via regex-based heuristics.

Comment 8

[Janika Neuberger [:janika]]

Fixed by Bug 1955655.

Comment 9

[Alin Ilea, Desktop Test Engineering]

Verified - Fixed in Nightly 138.0a1(2025-04-01). The address capture doorhanger is displayed and all the fields are captured and saved correctly.