form_embed.js Hides Third-Party Iframes Due to Overly Broad URL Pattern Matching
K
Kyle Bahr
Summary
The form_embed.js script (included with form/calendar embeds) unintentionally hides third-party iframes on the same page when their src URL contains path segments like /booking, /form, /survey, /quiz, /group, /rentals, or /service-menu.
Steps to Reproduce
- Embed a GHL form or calendar on a page that also contains a third-party iframe
- Ensure the third-party iframe src contains any of the above path segments (e.g. an Office 365 booking page at https://outlook.office365.com/owa/calendar/.../bookings/)
- Load the page
Expected Behavior
form_embed.js should only affect GHL-owned iframes and leave all third-party iframes untouched.
Actual Behavior
The Me() function in form_embed.js uses broad string matching (e.g. src.includes("/booking")) to identify GHL iframes. Any third-party iframe whose src URL happens to contain one of these path segments is incorrectly identified as a GHL iframe. It is then hidden via display:none / visibility:hidden by the de() function during initialization and never shown again, because it never sends the expected iframeLoaded postMessage that GHL uses to trigger the show sequence.
Affected URLs / Example
Third-party iframe src: https://outlook.office365.com/owa/calendar/***/bookings/
Matches because: src.includes("/booking") returns true
Root Cause
The Me() / Ie() filter in form_embed.js identifies GHL iframes purely by URL path segment pattern matching rather than by origin domain or a dedicated HTML attribute. This is not specific enough to distinguish GHL iframes from third-party iframes.
Workaround
A client-side interval loop is required to repeatedly force the hidden iframe back to visible after GHL's script runs, which is not a sustainable solution.
Please let me know if you need any additional detail or a reproduction case.
Log In