1463714 - [Form autofill] Credit Card autofill shouln't prompt to save if the number isn't valid using the Luhn algorithm

Status: RESOLVED WORKSFORME

(Toolkit :: Form Autofill, defect, P2)

Description

[Jens]

Attachment: bahncard-cc-bug.png

STR (using Nightly):

1. Go to bahn.de and book a train. (the german railway)
2. On page three or so of the checkout you are asked for your bahncard (the german railway's discount card, very popular). The bahncard, when already logged in, is already entered for you (server-side not by firefox autofill). Just leave as is. Probably all the same if not filled in server-side and you enter it yourself.
3. Click on "Next" button

AR:
This triggers the form autofill save popup. See attached screenshot. It looks like the 12digit bahncard number is considered to be a Credit Card by Firefox.

ER:
A bahncard is not a Credit Card, hence, it has nothing to do with Credit Cards and should not be considered like one. There should be no CC Save popup.


I don't know what kind of heuristics are used to recognize a CC form field. This is the html as used for the bahncard input field (excerpt, bahncard id masked by `9`s):

```
<tr>
<th class="col1"><label for="bahncardnummerNummer">Nummer Ihrer bisherigen<br>BahnCard / bahn.bonus Card<br>(falls vorhanden)</label></th>
<td colspan="3">7081&nbsp;<input name="bahncardnummerNummer" id="bahncardnummerNummer" value="999999998881" maxlength="12" size="17" type="text"></td>
								    
</tr>						
```

Maybe the value being 12-digits and also being a number triggers the heuristics?

PS I save the whole page locally, but since it includes personal data I can only make it available on request per mail or so (drop me a line if you need it). Hence only a screenshot and the excerpt.

Comment 1

[Matthew N. [:MattN]]

Hi Jens,

The issue is probably a known one that we don't use the Luhn Algorithm to check if a number is a credit card. Can you try enter your bahn number using the form at https://www.freeformatter.com/credit-card-number-generator-validator.html (with and without the 7081 prefix) and see if it uses the Luhn Algorithm… hopefully it doesn't.

Comment 2

[Jens]

For the 12 digit number (without the prefix) the test says it is an *invalid* number (which is correct). So I think that using the Luhn algorithm will fix this.

(As a side note: For the 16 digit number (with the prefix) the Luhn algorithm says that it would be valid. But I think this would not be an issue/problem here for the given page, because the 4 digit prefix is not part of the `<input>` field. Maybe that's even the reason why the Railway owner put it outside as text to avoid falsely CreditCard autofill triggers... (in Chrome or so))

Comment 3

[Daniel Bodea [:danibodea]]

Quick fact: When attempting to add a credit card with an incorrect card number from the Settings Saved Cards modal, it will not be saved (clicking the "Save" button will have no reaction). The actual issue is that a warning is not displayed, confusing the user.

Comment 4

[Jim Mathies [:jimm]]

We need to test to see if this is still an issue.

Comment 5

[Jim Mathies [:jimm]]

Testing with these test card numbers:

https://www.paypalobjects.com/en_US/vhelp/paypalmanager_help/credit_card_numbers.htm

The doorhanger shows for cards we support (Visa, Amex, DC, Discover, JCB, MC).

For 16 digit processor specific cards, the doorhanger also displays. But for non-16 digit cards, it does not.

This bug was about the doorhanger saving a non-standard 12 digit length card number (bahncard 9999 9999 8881). That no longer happens.

Seems like we're handling this correctly.