A clear symptom of broken custom JS is when you see form fields, in URL-encoded format, in the location bar after clicking Submit:
You should get to know the cause on sight: an uncaught error has been thrown in a custom Forms API . function
To replicate this, just set up an otherwise empty page with your form embed and this purposely bad JS:
form.oohlala(); // the property `form.oohlala` will never exist
This code won't throw any early errors on page load, because it doesn't have a syntax error. There's no way for the JS engine to know that will end up being a nonexistent method at runtime, it just adds the listener happily onto the form.
Here's the runtime error:
It's simple. Marketo forms use a true HTML ™) and standard / /etc. elements under the hood. tag (this is A Very Good Thing
The Forms API, among many other things, is responsible for transforming the standard W3C event into an elegant cross-domain POST to your Marketo instance.
In an error-free environment, the standard — that is, sending fields to the form's (destination URL) using its (HTTP method) — is turned off. The API's non-default actions take over. is swallowed by the Forms API's robust set of handlers. The event is triggered, but its default action
But when there's an error thrown within the Forms API listener stack, the form reverts to standard HTML form behavior as the default action doesn't get a chance to be turned off.
The Marketo , i.e. it looks basically like so: element doesn't have a specific or
When the button is clicked with this markup, and there's a JS error, the browser reverts to a standard GET of the current URL with form fields in the query string:
Whenever you see this behavior in your browser, realize your forms aren't working at all (even though the form seemingly "posts" somewhere). So fix ’em!
 Nor does the have the newfangled or attributes, which would be used if present.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.