13 Replies Latest reply on Feb 1, 2018 4:28 PM by Katie Blakey

    Progressive profiling breaking on number field

    Katie Blakey

      We're testing progressive profiling on a new form. Everything's working great until the user gets to a field where the field type is number (and the field type it maps to is an integer). For some reason,  on submitting the form, instead of showing the thank you message as it should (it's embedded on a page and our CMS controls the thank you message), it refreshes the page and adds the fields and my submissions as parameters at the end of the URL.

       

      We changed the field type to text and that fixed the issue. I'm sure we're not the first people to add a number field to a progressive profiling form -- has anyone encountered that issue before? Were you able to keep the field type as number, or did you need to change it to a dropdown or text field and add validation rules to only accept numerical characters?

       

      For now, we're removing it altogether and will add it back in when we have more time to test.

       

      Thanks for your help!

        • Re: Progressive profiling breaking on number field
          Sanford Whiteman

          You must provide a URL if you want people to look at this.

          • Re: Progressive profiling breaking on number field
            Keith Nyberg

            Agree with Sanford that a link would help. Have you tested the form submission to see if the values are captured in your MArketo instance regardless of the landing page behavior you mentioned?

            Might be an issue with you form submit re-direct but hard to assume without playing with the form.

              • Re: Progressive profiling breaking on number field
                Katie Blakey

                Hi Keith -- we've removed the problematic fields from our progressive profiling forms for now, and my team has submitted a case with Marketo, which has been escalated twice.

                 

                When someone filled out the form with the offending fields (one of which was number field, the other was a checkboxes field), the page would simply refresh, and either put the fields (and the person's responses) from the form as query parameters on the URL, or just add a weird query string to the end of it (something like "?aklid=123456"). The values they entered into the form were not captured in Marketo.

                 

                Once we get an answer back from Marketo support, I'll reply with whatever they discover to be the root cause of the issue.

                  • Re: Progressive profiling breaking on number field
                    Sanford Whiteman

                    Why won't you provide a link? I can tell you what the bug is much faster than they can.

                     

                    r just add a weird query string to the end of it (something like "?aklid=123456")

                    It's not weird, that's the form submission cache id (aliId). It's always attached to URLs after submission.

                    • Re: Progressive profiling breaking on number field
                      Sanford Whiteman

                      and either put the fields (and the person's responses) from the form as query parameters on the URL

                      This behavior occurs if you have a JavaScript bug that breaks the form logic, forcing the form to operate as a normal HTML form.

                      • Re: Progressive profiling breaking on number field
                        Sanford Whiteman

                        OK, found your LP w/form and your problem.

                         

                        As I suspected, it's not a Marketo problem, and you can close out your case.

                         

                        You have a bug in your custom form validation JS (in external file /mkto-form-validation.js).

                         

                        This code has a reference error if the variable t is not in a parent scope:

                        MktoForms2.whenReady(function (form) {
                            //listen for the validate event
                            form.onValidate(function () {
                                // Get the values
                                var vals = form.vals();
                                var check = true;
                                form.submittable(false);
                        
                                if ( vals.numberofAircraftMKTO != undefined && !isNaN(t.numberofAircraftMKTO) && parseInt(Number(t.numberofAircraftMKTO)) == t.numberofAircraftMKTO && !isNaN(parseInt(t.numberofAircraftMKTO, 10))) {
                                   console.log("invalid number of aircraft");
                                   form.showErrorMessage("Invalid number of aircraft. Please use a numeric value");
                                   check = false;
                                }
                        


                        When vals.numberofAircraftMKTO is not undefined, null or NaN, the next check (t.numberofAircraftMKTO) tries to access the object t instead of vals.

                         

                        So of course it throws a fatal error, form validation exits, and (as I suggested above) the form acts like a vanilla HTML <form>. (That's why you see form fields in the query string.)

                         

                        Your developer should've been able to spot this immediately, as there's an error in the console:

                         

                        P.S. The validation sequence itself is way too complex and confusing. It takes one condition to know if a number field can be safely cast to an int >= 1, not four!  That's not the bug per se, it's just unnecessary -- but a good lesson in how any extraneous code is just another place to create a bug.

                          • Re: Progressive profiling breaking on number field
                            Katie Blakey

                            Hi Sanford -- thanks for making the effort to look for the bug; however, we removed the impacted fields ("Number of Aircraft" (number field) and "What content are you interested in?" (checkboxes field)) from our live forms so that our users wouldn't get caught up in those errors. The code you referenced above is our potential workaround for this issue if Marketo can't figure it out -- basically, at the form level in Marketo, we'd change the type of the Number of Aircraft field to text (because text fields have been working fine for us), then use javascript rules to enforce only numeric characters to be entered so that the data that enters our database is in line with other values for that field.

                             

                            That code wasn't on the page when we were receiving the form errors I posted about. If you'd like to test out the original progressive profiling form this throwing up the error, this is the page that Marketo is testing:

                             

                            Formtest | Gogo Business Aviation

                             

                            Also, thanks for letting me know what was causing the form to append entered information as a parameter on the URL after submission -- I'll pass that on to my team. I'm getting that type of error now when I'm testing the form in the link above, so maybe that's what's causing it.

                             

                            Thanks for your help!

                              • Re: Progressive profiling breaking on number field
                                Sanford Whiteman

                                I know you removed the fields. I re-added them and tested with your external JS, and it could never work because of that reference error.

                                 

                                The link you just posted doesn't include the "Number of Aircraft" field.

                                  • Re: Progressive profiling breaking on number field
                                    Katie Blakey

                                    Thanks for that -- I'll pass that reference error on to our team. As I said, that's a potential workaround that we came up with after we discovered the issue, but we had emails that needed to go out and didn't have time to test it, so we just removed the problematic fields.

                                     

                                    The form on that page is progressive, so it'll take a few form fills before you get to the fields we've been having issues with:

                                     

                                    What topics are you interested in: after 3 form fills

                                    Number of aircraft: after 8 form fills

                                     

                                    For some reason, we only have an issue with these fields in the context of a progressive profiling form. When they're on standard form, even on a non-Marketo landing page, we haven't been seeing this issue.

                                     

                                    Thanks!

                                      • Re: Progressive profiling breaking on number field
                                        Sanford Whiteman

                                        Again, check your browser console:

                                         

                                        This fatal error fires every time numeric field changes. It comes from this extra custom form behaviors script you're loading for some reason (not from Marketo's code):

                                         

                                            https://business.gogoair.com/ScriptResource.axd?d=x6wALODbMJK5e0eRC_p1LQVbFzXKuOIGpQVfJZ0u6_rz9I2-lFy2Dyi8OqMtXFtBVIWT27…

                                         

                                        Because of the fatal error, the form validation errors out and the form cannot be posted to Marketo.

                                         

                                        The technical cause is that that extra script overloads the native String#trim method (which is horrendous practice, since it's a standard ECMAScript method present in all browsers, even pre-modern browsers).

                                         

                                        The trim method is called by the Forms 2.0 library, as is perfectly reasonable. But you've replaced it with an incompatible method that might at first glance appear to be harmless and equivalent in functionality to the native method.

                                         

                                        String.prototype.trim = function () {
                                          return this.replace(/^\s+|\s+$/g, "")
                                        };
                                        

                                         

                                        This trim will work fine if called as a method on a String.

                                         

                                        Unlike the native method, it will not work if applied to a Number.

                                        This is because the native method coerces its input to a String before trimming it. Strings have replace. Numbers don't.

                                         

                                        Yet again I suggest you close out the Marketo case. They aren't going to figure this stuff out as they don't have the experience.

                                        • Re: Progressive profiling breaking on number field
                                          Sanford Whiteman

                                          Same applies to checkbox fields, which are stored as an Array, not a String, so again the third-party code breaks because of its bad trim (re)implementation:

                                           

                                          Again the problem has nothing to do with Marketo. Overwriting native prototype methods will have consequences. Never do it unless there's some specific bug (relative to the standard implementation) you need to fix in only one browser, or to accomplish a debugging need that you can't do any other way.

                                           

                                          P.S. I also noticed your email validator doesn't allow plus addresses, which are perfectly valid addresses used by GMail/GSuite users: