CS Forms - Possible Honeypot Input Bug

Beta
#1

Hi Charlie,

We have been experiencing random, silent submission failures on one of our forms and believe we have finally traced the cause to the honeypot input.

The default honeypot input (name="cs_honeypot") is hidden using the class cs-form-input-hidden, defined as:

.cs-form-input-hidden {
    display: none !important;
}

We discovered that this field is being populated intermittently by browser autofill (Chrome in particular), even though it has autocomplete="off".

From our research, browser autofill engines use heuristics rather than relying solely on the autocomplete attribute, and in some circumstances will populate hidden inputs that are present in the DOM. This behaviour is difficult to reproduce consistently because it depends on the individual user’s browser, saved autofill profile and other environmental factors.

Because the honeypot validation runs through the same validation pipeline as any other form field, an autofill-triggered value in the honeypot causes an otherwise legitimate submission to be rejected. In our case, this resulted in silent submission failures that took a considerable amount of time to diagnose, as they only affected specific users and could not be reproduced reliably.

As a workaround, I have replaced the default hiding class with an off-screen positioning technique:

.cs-form-input-no-display {
    position: absolute !important;
    left: -9999px !important;
    top: -9999px !important;
    width: 1px !important;
    height: 1px !important;
    overflow: hidden !important;
    display: block !important;
}

and added the following custom attributes to the honeypot input:

tabindex="-1"
aria-hidden="true"

Since making these changes, we have not yet experienced any further silent submission failures. Although this does not prove that display:none was the direct cause, it appears that changing the way the honeypot is hidden has altered browser autofill behaviour sufficiently to prevent the issue.

Does this make sense to you?

Thanks,
Christopher

#2

It’s hard to know the exact reason without being able to recreate it on my end. I have a feeling tabindex="-1" fixes this issue. Is there some autofill extension your users are using?

#3

Yes. This form is unlike most I have on any site, as the endusers are all agency and local government staff. Getting information from them has not been easy! One failed submitter today unexpectedly mentioned they used autocomplete when their form failed to send and was stuck in a static loop.

Using Claude, we discovered the probable cause of the failed submissions, which are extremely random and tend to be from the same organisations. Here are two of the links Claude found to do with autocomplete and password apps:

https://issues.chromium.org/issues/40223868

The form in question largely comprises of mandatory text, textarea and radio button fields - all very standard. It also uses the honeypot and nonce fields as the main security (no reCAPTCHA). The silent submission failures therefore had to be associated with one of these two fields

I hope this helps.