Duplicate Form Submisisons | Community
Skip to main content
Brooke_Bartos1
Brooke_Bartos1
New Participant
December 4, 2018
Solved

Duplicate Form Submisisons

  • December 4, 2018
  • 1 reply
  • 4572 views

We have a client who has their forms iframed in, and something I've noticed is that for about 10 leads per month, their forms submit multiple times. It's a variety of different browsers and OS's, different forms, different regions, really no discernible pattern. Has anyone run into this? On the second submission URL there is a aliId= value in the query parameter that does not exist on initial form submissions. @Sanford Whiteman​?

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by SanfordWhiteman

So here's the thing.

The intent of the custom onSuccess listener on your page is to stay on the same page without refreshing and show a Thank You message. Ergo, there should never be a pageview with the ?aliId query parameter in the URL, because that only happens with the default (non-customized) onSuccess behavior (or if you deliberately emulate that same behavior in custom JS).

However, the onSuccess listener is added as part of a larger block of only semi-related code (starting on line 399) rather than standing alone. If any fatal error should happen in that code before the onSuccess is added (it's only added at the very end) then the rest of the code will never execute.  There are enough different functions in there that certainly something could go wrong under certain browser conditions. If that happens, the form will still submit, but it'll be using the default onSuccess behavior -- which is to refresh the IFRAME with the ?aliId and show the form again. That could well lead someone to think the form didn't do anything, as I mentioned.

As for what in those 100 lines of code could sometimes, but not always, error out, it's hard to say.  I see some very minor oversights (looking for fields starting with "utm" fields in the whole document, instead of just the current form, for example, and not securing postMessage as much as I'd like) but nothing that calls out as fragile. But I can all but guarantee that's what's happening: something else is erroring out, so the listener doesn't get overridden, so the end user thinks the form didn't get posted and tries again.

1 reply

SanfordWhiteman
SanfordWhiteman
New Participant
December 4, 2018

Please post a link to the offending page.

The aliId is the form data cache key. It exists on pages that have been loaded after a successful submit. So, as you've noted, that means the Thank You page then submits the form again.

My initial guess is you have some logic designed to auto-submit the form under some circumstances that's misfiring.

Or, of course, it could be that if you use the same page as the Thank You page without changing the page contents at all, the person doesn't think their form went anywhere (a not illogical assumption) and fills it out again.

    Brooke_Bartos1
    Brooke_Bartos1Author
    New Participant
    December 5, 2018

    There isn't any one specific offending page, they all seem to be guilty. The most common form in general is this: https://www.millerheimangroup.com/training/advanced-selling/strategic-selling-with-perspective/

    Thanks Sanford.

    SanfordWhiteman
    SanfordWhitemanAccepted solution
    New Participant
    December 6, 2018

    So here's the thing.

    The intent of the custom onSuccess listener on your page is to stay on the same page without refreshing and show a Thank You message. Ergo, there should never be a pageview with the ?aliId query parameter in the URL, because that only happens with the default (non-customized) onSuccess behavior (or if you deliberately emulate that same behavior in custom JS).

    However, the onSuccess listener is added as part of a larger block of only semi-related code (starting on line 399) rather than standing alone. If any fatal error should happen in that code before the onSuccess is added (it's only added at the very end) then the rest of the code will never execute.  There are enough different functions in there that certainly something could go wrong under certain browser conditions. If that happens, the form will still submit, but it'll be using the default onSuccess behavior -- which is to refresh the IFRAME with the ?aliId and show the form again. That could well lead someone to think the form didn't do anything, as I mentioned.

    As for what in those 100 lines of code could sometimes, but not always, error out, it's hard to say.  I see some very minor oversights (looking for fields starting with "utm" fields in the whole document, instead of just the current form, for example, and not securing postMessage as much as I'd like) but nothing that calls out as fragile. But I can all but guarantee that's what's happening: something else is erroring out, so the listener doesn't get overridden, so the end user thinks the form didn't get posted and tries again.

      Terms & ConditionsAccessibility statement

      Loading footer...