How to make input elements read-only in embedded scheduling widget using JavaScript?

Other Questions Calendly
1

I’ve got a scheduling widget embedded on my site as an iframe. I’m automatically filling some form fields with important data that I need for my API calls later. The problem is I don’t want users to modify the email field that gets pre-populated.

I tried using setInterval to continuously check for the input element and make it readonly, but document.getElementsByName doesn’t seem to find the element at all. Here’s what I attempted:

setInterval(function() {
    const emailField = document.getElementsByName('user_email')[0];
    if (emailField) {
        emailField.disabled = true;
    }
}, 1000);

The element never gets detected even though I can see it in the iframe. Is this because of cross-origin restrictions? What’s preventing me from accessing elements inside the embedded frame?

2

Indeed, cross-origin security policies restrict access to the DOM elements within the iframe. I faced a similar challenge with a third-party booking widget last year. The iframe operates in a security sandbox, preventing parent page JavaScript from interfacing with its content.

A workaround I discovered was to explore whether the widget provider offers URL parameters or configuration options. Many scheduling widgets allow pre-filling data via these parameters or JavaScript config objects during the embed process. Instead of modifying the fields post-load, set them to readonly directly from the widget’s side.

I suggest contacting your widget provider’s support team to inquire about readonly field options or initialization parameters. Most contemporary scheduling tools come equipped with such features, which are essential for developers. If they lack these functionalities, it raises concerns about the widget’s overall flexibility.

3

Had this exact problem with a calendar widget last month. Cross origin policies are blocking you, but here’s another approach.

Check if the widget loads form fields dynamically after the iframe loads. Your script might be running before the elements exist.

Try MutationObserver instead of setInterval to watch for when elements actually show up:

const observer = new MutationObserver(function(mutations) {
    // Watch for changes in the iframe
});

Still a long shot because of cross origin restrictions though.

I ended up switching to a different widget provider with better API controls. Look for widgets that let you set field properties during initialization.

Some providers let you pass readonly settings through embed parameters or config objects when loading the widget. Way cleaner than trying to hack it after.

4

Yeah, you’re hitting cross-origin restrictions. The browser blocks DOM access when iframe content comes from a different domain - that’s why getElementsByName isn’t finding anything.

Even if it worked, setInterval every second would be inefficient and slow your page down.

I’ve dealt with this before on embedded widgets. Best fix? Drop the iframe completely and build your own scheduling flow with proper automation.

Latenode lets you create scheduling workflows on your domain. You control readonly fields, pre-populate from APIs, and send data to your backend without cross-origin headaches.

You can add validation, conditional logic, and connect directly to existing systems. Much cleaner than fighting iframe restrictions.

5

you’re right about that cross-origin issue! using postMessage can help if the iframe supports it. if not, you’ll need to look for other options, like a different provider or maybe redesign the flow without iframes.