Determine if a JS variable is a Marketo form object vs. HTML ˂form˃ vs. other form-ish things

My latest UTM attribution library — my 5th go-round after Conversion Path, NanoTracker, and a couple of private ones! — manages hidden fields on Marketo forms, raw HTML <form>s, and a couple of other form types.

That means switching between different APIs:

if( type === "marketoForms2" ) {
  // call form.addHiddenFields()
} else if( type === "genericHTML" ) {
  // upsert `<input type="hidden">` and set value
} else if( type === "otherLibrary" ) {
  // use that library’s JS API
}

Admittedly, the easy way is to require a type hint, like:

updateHiddens( { form: obj, type: "marketoForms2" } );

Or maybe just:

updateHiddens( { marketoForms2: obj } );

But those are extra work for the end user, and I was sure the library could figure out on its own, letting you do:

updateHiddens( obj );

Adding more requirements to be flexible-slash-professional:

must work across Window objects — that is, a Marketo form in a child IFRAME must be detected as well
cannot rely on HTML attributes like class="mktoForm" or id="mktoForm_*" because a Marketo form still works even if those are removed after loading[1]
cannot rely solely on familiar JS functions being present, though functions may be called as an aid
may assume a global variable named MktoForms2 is the Marketo Forms 2.0 library
need not defend against deliberate attempts to fool the logic, i.e. expects to be called in good faith

What is a “Marketo form object”, anyway?

The argument passed to MktoForms2.whenReady() and several other Forms 2.0 methods is a Marketo form object. It’s a generic JS Object with function properties like setValues(), addHiddenFields(), getId(), and getFormElem().

Because it’s just an Object, rather than being an instance of a custom class, it doesn’t have a self-describing type. But we can look deeper to unravel whether it was generated by the Forms 2.0 library, or whether it’s merely an object with the same named properties.

Calling getFormElem() returns a jQuery wrapper containing the native <form> element at [0]. (That’s why you’ll see formEl = form.getFormElem()[0] in a lot of my code, because I prefer native DOM methods whenever possible.)

Every jQuery object is an instance of the jQuery library, and Marketo uses its own internal copy of jQuery: MktoForms2.$. Aha! That’s a simple way to know if Marketo created the form object:

if( form.getFormElem() instanceof MktoForms2.$ ) { 
  // …
}

We’d need to flesh that out to detect if the global forms library exists:

if( window.MktoForms2.$ && form.getFormElem() instanceof MktoForms2.$ ) { 
  // …
}

And also should check if getFormElem() is callable:

if( Object.prototype.toString.call(form.getFormElem) == "[object Function]" && window.MktoForms2.$ && form.getFormElem() instanceof MktoForms2.$ ) { 
  // …
}

(You’ll usually see typeof form.getFormElem == "function" but I’m using a more formal approach to be consistent with other stuff later.)

So far, so good. But remember requirement #1 above: the function needs to detect if form is a Marketo form object even if it’s owned by another window, i.e. passed between an IFRAME and its parent.

Detecting a Marketo form object from another window

MktoForms2 and your form may live inside a same-origin IFRAME, while the parent window only loads Munchkin.[2] In this case, window.MktoForms2 will always be undefined on the parent, though the parent and child can share form objects across the window boundary.[3]

So how do we solve for that? With a couple of DOM techniques you’ve probably never seen before, but which have been around for ages.

Every DOM Node, even one that isn’t currently connected to a document, has an ownerDocument property. That’s the document context in which it was originally created, e.g. someDocument.createElement("thing") sets ownerDocument to someDocument.

In turn, every document has a defaultView, which is its host window.

So if we unwrap the native <form> element inside the jQuery object from form.getFormElem(), we can get its document, get that document’s window, and check for MktoForms2 on the window. Whew!

Behold getFormDuckType():[4]

function getFormDuckType( form ) {
  
    if ( Object.prototype.toString.call(form.getFormElem) == "[object Function]" ) {
        const formElements = form.getFormElem(),
              MktoForms2Lib = formElements?.[0]?.ownerDocument?.defaultView?.MktoForms2;

        if( MktoForms2Lib && formElements instanceof MktoForms2Lib.$ ) {
           return "marketoForms2";
        }
    }
  
    if( Object.prototype.toString.call(form) == "[object HTMLFormElement]" ) {
        return "genericHTML";
    }

    /* 
    … other conditions…  
    */
}

Caveat: don’t be deliberately foolish!

As noted in requirement #5, I trust you won’t purposely try to fool the type detection code.

Like don’t useadoptNode() to move the underlying <form> element to another ownerDocument, or rename MktoForms2, or other stuff that breaks the Marketo form, just for the satisfaction of seeing the function fail!

But if you do encounter real-world scenarios where it doesn’t work, please let me know.

Notes

[1] OK, it’s pretty unlikely that you’d remove the class, though removing the id helps when you have multiple Marketo forms on the same page.

[2] Not a recommended setup, but still out there.

[3] Talking about direct access here, e.g. via window.parent.getFormDuckType(form) not via postMessage. With postMessage you can’t send Marketo form objects or HTMLFormElements because they can’t be structuredClone-d.

[4] https://en.wikipedia.org/wiki/Duck_typing

← TEKNKL :: Blog

What is a “Marketo form object”, anyway?

Detecting a Marketo form object from another window

Caveat: don’t be deliberately foolish!

Notes