Progressive profiling breaking on number field

[Anonymous]

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!

[SanfordWhiteman]

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

[Keith_Nyberg2]

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.

[Anonymous]

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.

[SanfordWhiteman]

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.

[SanfordWhiteman]

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.

[SanfordWhiteman]

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.

[Anonymous]

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!

[SanfordWhiteman]

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.

[Anonymous]

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!