1682161 - Credit card autofill doesn't work on bandcamp.com

Status: NEW

(Toolkit :: Form Autofill, defect, P3)

Description

[Chris Peterson [:cpeterson]]

Attachment: Bandcamp_screenshot.png

Steps to reproduce

1. Load https://theorb.bandcamp.com/album/the-cow-remixes-sin-in-space-pt-3 or any album page on https://bandcamp.com/ .
2. Click "Buy Digital Album".
3. One the "Name your price:" popup, enter a price and click the green "Check out now" button.
4. On the "How would you like to pay?" popup, select "Credit card" and click the blue "Proceed to payment" button.
5. An "Enter your payment details" page will open with an empty credit card form.

Actual result

The credit card form is empty, though my first and last names were autofilled. See the attached screenshot.

Inspecting Bandcamp's checkout page HTML, it looks like they use payment provider https://www.spreedly.com/:

<iframe sandbox="allow-scripts allow-same-origin" scrolling="no" id="spreedly-number-frame-2943" name="spreedly-number-frame-2943" src="https://core.spreedly.com/v1/embedded/number-frame.html?v=1.55" width="100%" height="100%" frameborder="0"></iframe>

Expected result

Firefox should autofill my saved credit card information or show the credit card autofill popup when I click in the credit card form.

Comment 1

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

Change the status for beta to have the same as nightly and release.
For more information, please visit auto_nag documentation.

Comment 2

[Dimi Lee [ooo 16.04 - 21.04］]

Hi Chris, would you mind testing if you can still reproduce this bug in the latest build? I guess this might also be fixed by Bug 1717603, thanks!

Comment 3

[Chris Peterson [:cpeterson]]

(In reply to Dimi Lee [:dimi] from comment #2)

Hi Chris, would you mind testing if you can still reproduce this bug in the latest build? I guess this might also be fixed by Bug 1717603, thanks!

I can still reproduce in Nightly 94 build 2021-09-08. Clicking or double-clicking the credit card number field does not show Firefox's form autofill menu. Also, if I click the "Enter your payment details" page's "First name" field, Firefox suggests autofilling my saved Zip code, not my first name.

All of the form fields on this website appear to be having trouble. When they get form autofilled, the filled result is not visible.

Comment 4

[Tim Giles [:tgiles]]

One of the issues is not being able to accurately determine the root form element. I'll post some cut down markup to demonstrate the issue:

<form class="class-entry-form">
  <iframe id="spreedly-number-frame">
    <form id="number-form">
      <input id="card_number" autocomplete="off">
    </form> <!-- number-form -->
  </iframe> <!-- spreedly-number-frame -->
  <fieldset class="date expiry-date">
    <select id="Ecom_Payment_Card_ExpDate_Month"></select>
    <select id="Ecom_Payment_Card_ExpDate_Year"></select>
  </fieldset>
  <div class="name-on-card">
    <div class="first-name">
      <input id="Ecom_BillTo_Postal_Name_First">
    </div>
    <div class="last-name">
      <input id="Ecom_BillTo_Postal_Name_Last">
    </div>
  </div> <!-- name-on-card -->
</form> <!-- class-entry-form -->

Since the credit card number is associated with its own form ("number-form"), our logic currently will grab the "number-form" as the root element and create a form handler based off that one element. Since there are no other fields associated with "number-form", we fail to identify this as a valid credit card section since hasCCNumber is true while ccNumberReason does not exist, so false, and we don't have an expiry date or cc name associated with this one member form...thus preventing the popup from appearing.

Additionally, since "number-form" is its own form...we don't take this form into consideration with the rest of the fields in "class-entry-form". I.e. the first name field's form attribute starts at the expiry date, not the card number, which causes issues with the rest of the logic. Since we don't have a cc-number associated with this form, we will end up not counting the rest of this form as a valid section. We end up only creating a credit card section that includes the expiry month and year, but since they're select elements wrapped in a fieldset there's no way to make the autocomplete popup appear since fieldset fields are ineligible for autofill. The previous paragraph assumes we correctly identify these fields as credit card fields, but we identify them as address fields instead!

As for why the popup doesn't appear as expected, at least for the rest of the elements, this appears to be because of the ID used for some of the input elements. Since the first and last name inputs have an id of "Ecom_BillTo_Postal_Name_", we attempt to get the autocomplete info via "getInfo" (which "getInfo" is called from "pushDetail" and "pushDetail" is called by "_parsePhoneFields" eventually.) which calls _findMatchedFieldName. "_findMatchedFieldName" uses some heuristic regexes to determine what kind of field if the field doesn't already have some autocomplete attributes. Unfortunately, we end up turning these name inputs into postal-code inputs because of the ID string on them. We appear to call our list of regexes in the same order, where the postal-code check happens before the name, family-name, given-name, etc checks. In other words, we check fields to see if they match addresses before we check to see if they match credit cards.

I'll have to give this some more thought before I can come up with a solution that solves all this. I'll end up breaking this problem up into smaller solutions, since we have a few sub-problems that can be parsed out.

I wonder if this works as expected on Chrome and Safari, as this is a complicated heuristics case.

Comment 5

[Tim Giles [:tgiles]]

Changing severity to S3 because one can still manually enter credit card information.