1767130 - [US] [orders.modpizza.com] CC autofill fills in incorrect expiry date format

Status: RESOLVED FIXED

(Toolkit :: Form Autofill, defect)

Description

[Hmmwhatsthisdo]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:99.0) Gecko/20100101 Firefox/99.0

Steps to reproduce:

1. Create a new carryout order at orders.modpizza.com
2. Proceed to checkout (Basket link in upper-right -> Checkout)
3. Select "checkout as a guest"
4. Fill in name/email/number fields for carryout pickup
5. Pick "New Card" and trigger CC autofill

Actual results:

Expiry date was filled in M/YY format (no leading 0 on month), causing form validation to fail

Expected results:

Expiry date should have been filled with leading 0

Comment 1

[Tim Giles [:tgiles]]

Attachment: image.png

modpizza uses an iframe for the card number field that also contains hidden credit card fields such as expiry month, expiry year, and cvv. The website then uses these hidden fields to fill in the visible expiry field. Since the hidden expiry fields don't have any placeholders associated with them, we fill them with the default format. So if you had a saved credit card of 04/25, the hidden expiry fields would be filled with "4" and "25" respectively. If you happened to have a saved credit card with 10, 11, or 12 for the expiry month, then autofill would appear to work as expected. I have a feeling capturing card details on this site might be difficult, but that's not the scope of this bug.

We can either do nothing and say this is a website specific issue or we could change the default fill format of expiry month to be "04" instead of "4". This change would probably fix United States sites, but may cause issues with other locales...but I'm not entirely sure. Like credit cards are physically formatted such that the expiry month is always padded with a zero so that its two characters long. This would also resolve any localization issues with our current expiry month placeholder logic, since we would always transform the expiry month into a two character string (at least in cases where the expiry fields are separate in the credit card form).

:serg, :dimi, do either of yall see any issues with always transforming credit card expiry month into a two character zero-padded string?

Comment 2

[Dimi Lee [:dimi]]

(In reply to Tim Giles [:tgiles] from comment #1)

:serg, :dimi, do either of yall see any issues with always transforming credit card expiry month into a two character zero-padded string?

I agree with using two character zero-padded string because

1. We already use two character zero-padded string for cc-exp
2. It looks like this is the preferred default format (I test both Chrome and Safari, they fill two character zero-padded string)

Comment 3

[Sergey Galich [:serg]]

While I don't have data to support this, I think most sites are using 04 for April. Lets try it.

Do you think we can also look into the option elements of expiry month to guess what values they are expecting?

Comment 4

[Tim Giles [:tgiles]]

Alright, I'll go ahead and get a patch for this sometime soon.

(In reply to Sergey Galich from comment #3)

Do you think we can also look into the option elements of expiry month to guess what values they are expecting?

If I understand your question correctly, we already do that as a transformer in FormAutofillHandler.matchSelectOptions.

Comment 5

[Tim Giles [:tgiles]]

Attachment: Bug 1767130 - Fix default fill format for cc-exp-month input elements to MM. r=dimi!,sgalich!

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4a5a51340bc8
Fix default fill format for cc-exp-month input elements to MM. r=dimi,sgalich

Comment 7

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/4a5a51340bc8