Wednesday, November 19, 2025
HomeProgrammingIframe Enable Attribute Saga – CodePen

Iframe Enable Attribute Saga – CodePen


There was a day not way back the place a Google Chrome browser replace left any web page with a CodePen Embed on it throwing an entire large pile of purple JavaScript errors within the console. Not excellent, clearly.

The change was associated to how the browser handles enable attributes on iframes (i.e. <iframe enable="...">). CodePen was calculating the suitable values inside an iframe for a nested iframe. That will need to have been a safety challenge of kinds, as now these values must be current on the exterior iframe as properly.

We documented all this in a weblog publish so hopefully we may get some consideration from Chrome on this, and for different browser makers as properly because it impacts all of us.

And I posted it on the ol’ social media:

Large because of Bramus Van Damme who noticed this, triaged it at Chrome, and had a decision inside a day:

I adopted up on this one with engineering (points.chromium.org/points/45408…), and we selected a small tweak to solely present these console messages when a reporting endpoint is ready.The tweak landed in Chrome 143.0.7490.0 (present Canary)(See subsequent message for earlier than and after screenshots)

Bramus (@bram.us) 2025-10-24T12:21:00.246Z

I feel the patch is a good change so hats off to everybody concerned for getting it finished so rapidly. It’s already in Canary and don’t actually know when it’ll get the secure however that positive shall be good. It follows how Safari is doing issues the place values that aren’t understood are simply ignored (which we predict is okay and inline with how HTML usually works).

Fortuitously we had been in a position to mitigate the issue somewhat till then. For most Embedded Pens, a <script> is loaded on the web page embedding it, and we dynamically create the <iframe> for you. That is simply good because it makes making an accessible fallback simpler and offers you entry to API-ish options for the embeds. We had been in a position to increase that script to do some browser user-agent sniffing and apply the right set of enable attributes on the iframe, as to keep away from these JavaScript errors we had been seeing.

However there’s the rub: we’d quite not do any user-agent sniffing in any respect.

If we may simply put all the doable enable attributes we wish on there, and never be terribly involved if any specific browser didn’t assist any specific worth, that will be excellent. We simply can’t have the scary console errors, out of concern for our customers who could not perceive them.

The place we’re at within the saga now could be that:

  1. We’re ready for the change to Chrome to get to secure.
  2. We’re hoping Safari stays the best way it’s.
  3. OH HI FIREFOX.

On that final level, if we put all of the enable attributes we’d need to on an <iframe> in Firefox, we additionally get console-bombed. This time not with red-errors however with yellow-warnings.

So sure, hello Firefox, if you happen to may additionally not show these warnings (except a reporting URL is ready up) that will be nice. We’d be one much less web site on the market counting on user-agent sniffing.

RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

- Advertisment -
Google search engine

Most Popular

Recent Comments