Closed Bug 1835852 Opened 1 years ago Closed 1 year ago

[US][nike.com] The State field is not captured in the Address Save/Update doorhanger

Categories

(Toolkit :: Form Autofill, defect, P3)

Firefox 115
defect

Tracking

()

VERIFIED FIXED
120 Branch
Tracking Status
firefox-esr102 --- unaffected
firefox-esr115 --- disabled
firefox113 --- disabled
firefox114 --- disabled
firefox115 --- disabled
firefox116 --- wontfix
firefox117 --- wontfix
firefox118 --- wontfix
firefox119 --- wontfix
firefox120 --- verified

People

(Reporter: ailea, Assigned: janika)

References

(Blocks 1 open bug, Regression, )

Details

(Keywords: regression, Whiteboard: [fxcm-addr-compatibility])

Attachments

(3 files)

Attached video 2023-05-30_14h36_19.mp4

Found in

  • Nightly 115.0a1 (2023-05-30)

Affected versions

  • Nightly 115.0a1 (2023-05-30)

Tested platforms

  • Affected platforms: Windows 10

Preconditions

  • browser.search.region to US
  • extensions.formautofill.addresses.capture.v2.enabled = true

Steps to reproduce

  1. Reach the address form on https://www.nike.com
  2. Fill in manually new Address info and submit the form

Expected result

  • The complete address should be captured and stored with all the available info.

Actual result

  • The State field (dropdown) is not captured in the Address save doorhanger and not saved in the Address manager.

Regression range

  • N/A

Additional notes

:ailea, if you think that's a regression, could you try to find a regression range using for example mozregression?

Priority: -- → P3
Depends on: 1836468
Whiteboard: [fxcm-addr-compatibility]

This issue should be fixed by Bug 1836468

Status: NEW → RESOLVED
Closed: 1 year ago
Flags: qe-verify+
Resolution: --- → FIXED
Attached video 2023-07-19_16h44_36.mp4

Unfortunately, I am still able to reproduce the issue in the latest Nightly build 117.0a1. The State field is still not captured in the Address save doorhanger and it is not saved in the Address Manager.

Flags: needinfo?(dlee)
Status: RESOLVED → REOPENED
Flags: needinfo?(dlee)
Resolution: FIXED → ---

Hi emilio,
In credit card/address autofill, when we run our heuristic to determine the type of a <input> or <select> field, we use checkVisibility API first to filter out elements that are invisible[1].
However, when running checkVisibility on the State field of the address form in nike.com, the API returns false. Could you help check whether this is expected? Thank you!

[1] https://searchfox.org/mozilla-central/rev/8d43262674d6c6d469b821cca579b1240ebb42a5/toolkit/components/formautofill/shared/FormAutofillUtils.sys.mjs#440-448

Flags: needinfo?(emilio)

It is invisible, right?

.css-1jjxzuj select {
  width: 100%;
  box-sizing: border-box;
  border-radius: var(--podium-cds-size-border-radius-s);
  outline: 0px;
  appearance: none;
  opacity: 0;
}

(In particular the opacity: 0)

It's just overlaid over the content.

Flags: needinfo?(emilio)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #5)

It is invisible, right?

indeed, thank you for checking!

Type: task → defect
Keywords: regression
Regressed by: 1833618

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

See Also: → 1847687

This is fixed by Bug 1847687, because we now check a field's focusability instead of visibility when considering it for filling or capturing.

Status: REOPENED → RESOLVED
Closed: 1 year ago1 year ago
Resolution: --- → FIXED
Assignee: nobody → jneuberger
Depends on: 1847687
Target Milestone: --- → 120 Branch

Verified - Fixed in the latest Nightly 120.0a1 (2023-10-19).

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

Attachment

General

Created:
Updated:
Size: