Closed Bug 1743629 Opened 2 years ago Closed 2 years ago

Credit card expiration date autofills with 12/2021 instead of the saved date

Categories

(Toolkit :: Form Autofill, defect, P2)

Firefox 94
defect

Tracking

()

VERIFIED FIXED
102 Branch
Tracking Status
firefox94 --- wontfix
firefox95 --- wontfix
firefox96 --- wontfix
firefox100 --- wontfix
firefox101 --- wontfix
firefox102 --- verified
firefox103 --- verified

People

(Reporter: dave.veronica, Assigned: tgiles)

Details

Attachments

(3 files, 1 obsolete file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:94.0) Gecko/20100101 Firefox/94.0

Steps to reproduce:

This bug can be reproduced on Paypal's credit card checkout page, but I have seen it on other websites as well.

  1. Save credit card information in Firefox using an expiration date in the future.
  2. Go to a Paypal checkout page and choose to pay with debit or credit card.
  3. Allow Firefox to autofull credit card information.

Actual results:

Firefox autofilled the expiration date with the current month and year rather than the saved credit card expiration date.

Expected results:

Firefox should have autofilled the expiration date with the saved credit card expiry date information.

Summary: Credit card expiration date autofills with the current month and year instead of the saved date → Credit card expiration date autofills with 12/2021 instead of the saved date

I edited the title because I realized that it is specifically autofilling the form with 12/2021, and today is November 30, 2021, so I was incorrect about it being the current month and year.

The Bugbug bot thinks this bug should belong to the 'Toolkit::Form Autofill' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Form Autofill
Product: Firefox → Toolkit

Hi Timea, Could you help check if you can reproduce this issue? Thanks!

Flags: needinfo?(timea.babos)
Attached image Repro GIF

This also reproduces on Nightly amd64 Windows 96.0a1 (2021-11-30). GIF attached.
I had to get to a PayPal page that offered a credit card field without requiring a login. In this case, I visited https://www.dirksfund.com.

In the GIF, I am using a credit card set to expire in 09/2027.

Yes, this issue is also reproducible on the latest Nightly 96.0a1 (2021-12-01) (64-bit) and Release 94.0.2. on MacOS 10.15.
Thanks for the link from Comment 4 Dustin! Easily reproducible with that one.
On a different note, if I choose any other Region from the dropdown (Germany, Romania, etc) the Expiry Date will not be autofilled at all, remains blank with the yellow highlight.

Flags: needinfo?(timea.babos)
Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2

Noticed a similar issue on another credit card entry form.

Steps to reproduce:

  1. Save credit card information in Firefox.
  2. Visit https://shop.armstronggarden.com and add item to cart.
  3. Go to https://shop.armstronggarden.com/checkout and allow Firefox to autofill credit card information.
  4. Credit card is autofilled with the first 2 digits of the year as the month value (in other words, an expiration date of 09/2025 would become 20/25).

For the Paypal/https://www.dirksfund.com/ case, there is custom website handling on the expiry field that is specifically looking for the "MM/YY" or "MM/YYYY" formats for expiry dates. In most cases, we transform our default fill format from "YYYY-MM" to "MM/YYYY" because of this situation, unless there is a placeholder on the field. There happens to be a placeholder on the expiry field, but it is a whitespace character. Because of this, our placeholder logic kicks in and we try to transform "YYYY-MM" into the placeholder format, which in this case, will just return "YYYY-MM" since there's nothing to match. It seems like we can just trim the placeholder value before our initial check, which should transform the expiry date to "MM/YYYY" and then the website should be able to handle the expiry date as expected.

As for the https://shop.armstronggarden.com/ case, there is also custom website handling on the expiry field. We do fill "MM/YYYY" which is closer to what the website is looking for, but then the website cuts the wrong part of the four digit year so "05/2025" becomes "05/20" which is incorrect. There is a label next to the input that has the format expected for the expiry field, which is decent. It would be nice if this expiry value was a placeholder in the form itself, then the fill would just work™. We could add some logic to the creditCardExpiryDateTransformer but determining what elements to look for, and how to parse these found elements...seems like it could get out of hand quickly. It seems reasonable that we can use element.previousSibling since the describing label should be before the input field, and we already have logic for parsing expiration date strings.

I'll see if I can get some patches for these issues.

Assignee: nobody → tgiles
Status: NEW → ASSIGNED

When there is a label element right before a credit card expiry input, we will try and parse this label
as a placeholder. This allows our autofill to work as expected in cases where
the label is not wrapped around the expiry input.

Depends on D145025

Attachment #9274341 - Attachment description: Bug 1743629 - Use mm/yyyy expiry date transformation when placeholder is an empty string. r=dimi!,sgalich! → Bug 1743629 - Use mm/yyyy expiry date transformation when placeholder is a whitespace string. r=dimi!,sgalich!
Attachment #9274341 - Attachment is obsolete: true
Pushed by tgiles@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/53419507bacf
Use adjacent label as placeholder format for cc-exp transformer. r=dimi,sgalich
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 102 Branch
Flags: qe-verify+

Verified as fixed on macOS 11.6, Windows 10 x64, Ubuntu 20.04 x64 on Firefox 102.0b3 and Nightly 103.0a1.

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: