4 Replies Latest reply on Dec 6, 2018 8:05 AM by Brooke Bartos

    Duplicate Form Submisisons

    Brooke Bartos

      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?

        • Re: Duplicate Form Submisisons
          Sanford Whiteman

          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.

            • Re: Duplicate Form Submisisons
              Brooke Bartos

              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.

                • Re: Duplicate Form Submisisons
                  Sanford Whiteman

                  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.