Hello @Dstepchew,

That is an odd behavior! Thanks for bringing it to our attention! 

Out of curiosity does this issue persist on a Google Chrome browser? 

I’m going to flag this observation to our Product and Engineering teams to investigate further. I’ll share an update on this thread with news I hear from our internal teams regarding this matter.

Thanks for being a member of the Klaviyo Community!

David

Thanks @David To - Yes, happening on both Safari and Chrome. Looking forward to a resolution as it’s really cumbersome to have to manually adjust the max-height on the iframe just to edit the email properly. Keep me posted.

-Dan

Hey @Dstepchew,

I had a chance to speak with one of our Templates Engineering team members surrounding this behavior and it was highlighted to me that this may be caused by a race condition. The height value for iframe within the editor are dynamically calculated at the time the template is loaded. 

They’ve seen this behavior prior where some content within the template is causing a race condition where the value is calculated before all the content is rendered. By chance, are there any custom HTMLs within the template?

From your brief loom video, our team members noticed elements that were not inherent to Klaviyo (Blocks that mentioned “powered by HTML.com”) and suspect that those elements would be the root cause of the race condition. 

I would recommend reviewing those elements and potentially working with an email designer to review those sections of the email.

David

Hey @David To - yes, I am using custom HTML but nothing dynamic beyond what’s available in your documentation. Everything in your template editor is inherently loading HTML, is it not? For example, what would be the difference if I loaded a page full of Klaviyo HTML blocks vs. a template with HTML in it? Anything I have in there would just be placeholder text/html with minimal load times. Wouldn’t a race condition be something your engineering team would be controlling for?