There was a day not long ago where a Google Chrome browser update left any page with a CodePen Embed on it throwing a whole big pile of red JavaScript errors in the console. Not ideal, obviously. 



The change was related to how the browser handles allow attributes on iframes (i.e. &lt;iframe allow="...">). CodePen was calculating the appropriate values inside an iframe for a nested iframe. That must have been a security issue of sorts, as now those values need to be present on the outside iframe as well.



<a href="https://blog.codepen.io/2025/10/20/google-chrome-iframe-allow-permissions-problems/">We documented all this in a blog post</a> so hopefully we could get some attention from Chrome on this, and for other browser makers as well since it affects all of us. 



And I posted it on the ol' social media:





Huge thanks to Bramus Van Damme who saw this, triaged it at Chrome, and had a resolution within a day:





I think <a href="https://chromium-review.googlesource.com/c/chromium/src/+/7074672">the patch</a> is a great change so hats off to everyone involved for getting it done so quickly. It's already in Canary and don't really know when it'll get the stable but that sure will be good. It follows how Safari is doing things where values that aren't understood are just ignored (which we think is fine and inline with how HTML normally works). 



Fortunately we were able to mitigate the problem a little until then. For most Embedded Pens, a &lt;script> is loaded on the page embedding it, and we dynamically create the &lt;iframe> for you. This is just nice as it makes making an accessible fallback easier and gives you access to API-ish features for the embeds. We were able to augment that script to do a little browser user-agent sniffing and apply the correct set of allow attributes on the iframe, as to avoid those JavaScript errors we were seeing.



But there's the rub: we'd rather not do any user-agent sniffing at all. 



If we could just put all the possible allow attributes we want on there, and not be terribly concerned if any particular browser didn't support any particular value, that would be ideal. We just can't have the scary console errors, out of concern for our users who may not understand them. 



Where we're at in the saga now is that:



<ol class="wp-block-list">
<li>We're waiting for the change to Chrome to get to stable.</li>



<li>We're hoping Safari stays the way it is.</li>



<li>OH HI FIREFOX.</li>
</ol>



On that last point, if we put all the allow attributes we would want to on an &lt;iframe> in Firefox, we also get console-bombed. This time not with red-errors but with yellow-warnings. 





So yes, hi Firefox, if you could also not display these warnings (unless a reporting URL is set up) that would be great. We'd be one less website out there relying on user-agent sniffing.

<description>&lt;p&gt;There was a day not long ago where a Google Chrome browser update left any page with a CodePen Embed on it throwing a whole big pile of red JavaScript errors in the console. Not ideal, obviously. &lt;/p&gt;



&lt;p&gt;The change was related to how the browser handles allow attributes on iframes (i.e. &amp;lt;iframe allow="..."&gt;). CodePen was calculating the appropriate values inside an iframe for a &lt;em&gt;nested&lt;/em&gt; iframe. That must have been a security issue of sorts, as now those values need to be present on the &lt;em&gt;outside&lt;/em&gt; iframe as well.&lt;/p&gt;



&lt;p&gt;&lt;a href="https://blog.codepen.io/2025/10/20/google-chrome-iframe-allow-permissions-problems/"&gt;We documented all this in a blog post&lt;/a&gt; so hopefully we could get some attention from Chrome on this, and for other browser makers as well since it affects all of us. &lt;/p&gt;



&lt;p&gt;And I posted it on the ol' social media:&lt;/p&gt;





&lt;p&gt;Huge thanks to Bramus Van Damme who saw this, triaged it at Chrome, and had a resolution within a day:&lt;/p&gt;





&lt;p&gt;I think &lt;a href="https://chromium-review.googlesource.com/c/chromium/src/+/7074672"&gt;the patch&lt;/a&gt; is a great change so hats off to everyone involved for getting it done so quickly. It's already in Canary and don't really know when it'll get the stable but that sure will be good. It follows how Safari is doing things where values that aren't understood are just ignored (which we think is fine and inline with how HTML normally works). &lt;/p&gt;



&lt;p&gt;Fortunately we were able to mitigate the problem &lt;em&gt;a little&lt;/em&gt; until then. For &lt;em&gt;most&lt;/em&gt; Embedded Pens, a &amp;lt;script&gt; is loaded on the page embedding it, and we dynamically create the &amp;lt;iframe&gt; for you. This is just nice as it makes making an accessible fallback easier and gives you access to API-ish features for the embeds. We were able to augment that script to do a little browser user-agent sniffing and apply the correct set of allow attributes on the iframe, as to avoid those JavaScript errors we were seeing.&lt;/p&gt;



&lt;p&gt;But there's the rub: we'd rather not do any user-agent sniffing at all. &lt;/p&gt;



&lt;p&gt;If we could just put &lt;em&gt;all&lt;/em&gt; the possible allow attributes we want on there, and not be terribly concerned if any particular browser didn't support any particular value, that would be ideal. We just can't have the scary console errors, out of concern for our users who may not understand them. &lt;/p&gt;



&lt;p&gt;Where we're at in the saga now is that:&lt;/p&gt;



&lt;ol class="wp-block-list"&gt;
&lt;li&gt;We're waiting for the change to Chrome to get to stable.&lt;/li&gt;



&lt;li&gt;We're hoping Safari stays the way it is.&lt;/li&gt;



&lt;li&gt;OH HI FIREFOX.&lt;/li&gt;
&lt;/ol&gt;



&lt;p&gt;On that last point, if we put all the allow attributes we would want to on an &amp;lt;iframe&gt; in Firefox, we also get console-bombed. This time not with red-errors but with yellow-warnings. &lt;/p&gt;





&lt;p&gt;So yes, hi Firefox, if you could also not display these warnings (unless a reporting URL is set up) that would be great. We'd be one less website out there relying on user-agent sniffing. &lt;/p&gt;</description>

There was a day not long ago where a Google Chrome browser update left any page with a CodePen Embed on it throwing a whole big pile of red JavaScript errors in the console. Not ideal, obviously. 



The change was related to how the browser handles allo

There was a day not long ago where a Google Chrome browser update left any page with a CodePen Embed on it throwing a whole big pile of red JavaScript errors in the console. Not ideal, obviously. 



The change was related to how the browser handles allow attributes on iframes (i.e. &lt;iframe allow="...">). CodePen was calculating the appropriate values inside an iframe for a nested iframe. That must have been a security issue of sorts, as now those values need to be present on the outside iframe as well.



We documented all this in a blog post so hopefully we could get some attention from Chrome on this, and for other browser makers as well since it affects all of us. 



And I posted it on the ol' social media:





Huge thanks to Bramus Van Damme who saw this, triaged it at Chrome, and had a resolution within a day:





I think the patch is a great change so hats off to everyone involved for getting it done so quickly. It's already in Canary and don't really know when it'll get the stable but that sure will be good. It follows how Safari is doing things where values that aren't understood are just ignored (which we think is fine and inline with how HTML normally works). 



Fortunately we were able to mitigate the problem a little until then. For most Embedded Pens, a &lt;script> is loaded on the page embedding it, and we dynamically create the &lt;iframe> for you. This is just nice as it makes making an accessible fallback easier and gives you access to API-ish features for the embeds. We were able to augment that script to do a little browser user-agent sniffing and apply the correct set of allow attributes on the iframe, as to avoid those JavaScript errors we were seeing.



But there's the rub: we'd rather not do any user-agent sniffing at all. 



If we could just put all the possible allow attributes we want on there, and not be terribly concerned if any particular browser didn't support any particular value, that would be ideal. We just can't have the scary console errors, out of concern for our users who may not understand them. 



Where we're at in the saga now is that:




We're waiting for the change to Chrome to get to stable.



We're hoping Safari stays the way it is.



OH HI FIREFOX.




On that last point, if we put all the allow attributes we would want to on an &lt;iframe> in Firefox, we also get console-bombed. This time not with red-errors but with yellow-warnings. 





So yes, hi Firefox, if you could also not display these warnings (unless a reporting URL is set up) that would be great. We'd be one less website out there relying on user-agent sniffing.

417: Iframe Allow Attribute Saga

Shaw and Chris are on the show to talk about the thinking and challenges behind upgrading these rather important bits of technology in our stack. We definitely think of React version upgrades and Next.js version upgrades as different things. Sometimes they are prerequisites. The Next.js ones are a bit more important as 1) the docs for the most recent version tend to be the best and 2) it involves server side code which is important for security reasons. Never has any of it been trivially easy.



<h2 class="wp-block-heading">Time Jumps</h2>

<description>&lt;p&gt;Shaw and Chris are on the show to talk about the thinking and challenges behind upgrading these rather important bits of technology in our stack. We definitely think of React version upgrades and Next.js version upgrades as different things. Sometimes they are prerequisites. The Next.js ones are a bit more important as 1) the docs for the most recent version tend to be the best and 2) it involves server side code which is important for security reasons. Never has any of it been trivially easy.&lt;/p&gt;



&lt;h2 class="wp-block-heading"&gt;Time Jumps&lt;/h2&gt;</description>

Shaw and Chris are on the show to talk about the thinking and challenges behind upgrading these rather important bits of technology in our stack. We definitely think of React version upgrades and Next.js version upgrades as different things. Sometimes th

Shaw and Chris are on the show to talk about the thinking and challenges behind upgrading these rather important bits of technology in our stack. We definitely think of React version upgrades and Next.js version upgrades as different things. Sometimes they are prerequisites. The Next.js ones are a bit more important as 1) the docs for the most recent version tend to be the best and 2) it involves server side code which is important for security reasons. Never has any of it been trivially easy.



Time Jumps

416: Upgrading Next.js & React

Robert and Chris hop on the show to talk about choices we've had to make around <a href="https://babeljs.io/">Babel</a>. 



Probably the best way to use Babel is to just use the <a href="https://babeljs.io/docs/babel-preset-env">@babel/preset-env</a> plugin so you get modern JavaScript features processed down to a level of browser support you find comfortable. But Babel supports all sorts of plugins, and in our Classic Editor, all you do is select "Babel" from a dropdown menu and that's it. You don't see the config nor can you change it, and that config we use does not use preset env. 



So we're in an interesting position with the 2.0 editor. We want to give new Pens, which do support editable configs, a good modern config, and we want all converted Classic Pens a config that doesn't break anything. There is some ultra-old cruft in that old config, and supporting all of it felt kinda silly. We could support a "legacy" Babel block that does support all of it, but so far, we've decided to just provide a config that handles the vast majority of old stuff, while using the same Babel block that everyone will get on day one. 



We're still in the midst of working on our conversion code an verifying the output of loads of Classic Pens, so we'll see how it goes!



<h2 class="wp-block-heading">Time Jumps</h2>

<description>&lt;p&gt;Robert and Chris hop on the show to talk about choices we've had to make around &lt;a href="https://babeljs.io/"&gt;Babel&lt;/a&gt;. &lt;/p&gt;



&lt;p&gt;Probably the best way to use Babel is to just use the &lt;a href="https://babeljs.io/docs/babel-preset-env"&gt;@babel/preset-env&lt;/a&gt; plugin so you get modern JavaScript features processed down to a level of browser support you find comfortable. But Babel supports all sorts of plugins, and in our Classic Editor, all you do is select "Babel" from a dropdown menu and that's it. You don't see the config nor can you change it, and that config we use does &lt;em&gt;not&lt;/em&gt; use preset env. &lt;/p&gt;



&lt;p&gt;So we're in an interesting position with the 2.0 editor. We want to give new Pens, which do support editable configs, a good modern config, and we want all converted Classic Pens a config that doesn't break anything. There is some ultra-old cruft in that old config, and supporting &lt;em&gt;all&lt;/em&gt; of it felt kinda silly. We could support a "legacy" Babel block that does support all of it, but so far, we've decided to just provide a config that handles the vast majority of old stuff, while using the same Babel block that everyone will get on day one. &lt;/p&gt;



&lt;p&gt;We're still in the midst of working on our conversion code an verifying the output of loads of Classic Pens, so we'll see how it goes!&lt;/p&gt;



&lt;h2 class="wp-block-heading"&gt;Time Jumps&lt;/h2&gt;</description>

Robert and Chris hop on the show to talk about choices weve had to make around Babel. 



Probably the best way to use Babel is to just use the @babel/preset-env plugin so you get modern JavaScript features processed down to a level of browser support yo

Robert and Chris hop on the show to talk about choices we've had to make around Babel. 



Probably the best way to use Babel is to just use the @babel/preset-env plugin so you get modern JavaScript features processed down to a level of browser support you find comfortable. But Babel supports all sorts of plugins, and in our Classic Editor, all you do is select "Babel" from a dropdown menu and that's it. You don't see the config nor can you change it, and that config we use does not use preset env. 



So we're in an interesting position with the 2.0 editor. We want to give new Pens, which do support editable configs, a good modern config, and we want all converted Classic Pens a config that doesn't break anything. There is some ultra-old cruft in that old config, and supporting all of it felt kinda silly. We could support a "legacy" Babel block that does support all of it, but so far, we've decided to just provide a config that handles the vast majority of old stuff, while using the same Babel block that everyone will get on day one. 



We're still in the midst of working on our conversion code an verifying the output of loads of Classic Pens, so we'll see how it goes!



Time Jumps

415: Babel Choices

Rachel and Chris jump on the show to talk about a bit of client-side technology we use: <a href="https://www.apollographql.com/">Apollo</a>. We use it because we have a GraphQL API and Apollo helps us write queries and mutations that go through that API. It slots in quite nicely with our React front-end, providing hooks we use to do the data work we need to do when we need to do it. Plus we get typed data all the way through.



Chris gets to learn that the Apollo Cache isn't some bonus feature that just helps makes things faster, but an inevitable and deeply integrated feature into how this whole thing works.



<h2 class="wp-block-heading">Time Jumps</h2>

<description>&lt;p&gt;Rachel and Chris jump on the show to talk about a bit of client-side technology we use: &lt;a href="https://www.apollographql.com/"&gt;Apollo&lt;/a&gt;. We use it because we have a GraphQL API and Apollo helps us write queries and mutations that go through that API. It slots in quite nicely with our React front-end, providing hooks we use to do the data work we need to do when we need to do it. Plus we get typed data all the way through.&lt;/p&gt;



&lt;p&gt;Chris gets to learn that the Apollo Cache isn't some bonus feature that just helps makes things faster, but an inevitable and deeply integrated feature into how this whole thing works.&lt;/p&gt;



&lt;h2 class="wp-block-heading"&gt;Time Jumps&lt;/h2&gt;</description>

Rachel and Chris jump on the show to talk about a bit of client-side technology we use: Apollo. We use it because we have a GraphQL API and Apollo helps us write queries and mutations that go through that API. It slots in quite nicely with our React fron

Rachel and Chris jump on the show to talk about a bit of client-side technology we use: Apollo. We use it because we have a GraphQL API and Apollo helps us write queries and mutations that go through that API. It slots in quite nicely with our React front-end, providing hooks we use to do the data work we need to do when we need to do it. Plus we get typed data all the way through.



Chris gets to learn that the Apollo Cache isn't some bonus feature that just helps makes things faster, but an inevitable and deeply integrated feature into how this whole thing works.



Time Jumps

414: Apollo (and the Almighty Cache)

We're over 13 years old as a company now. We decide that we're not a startup anymore (we're a "small business" with big dreams) but we are still indie. We've seen trends come and go. We just do what we do, knowing the tradeoffs, and plan to keep getting better as long as we can.



<h2 class="wp-block-heading">Links</h2>



<ul class="wp-block-list">
<li><a href="https://chriscoyier.net/timeline/">Timeline – Chris Coyier </a></li>



<li><a href="https://front-end-fire.com/episodes/115/">115: Adam Argyle on Cracking the 2025 Web Dev Interview | Front-End Fire</a></li>
</ul>



<h2 class="wp-block-heading">Time Jumps</h2>

<description>&lt;p&gt;We're over 13 years old as a company now. We decide that we're not a startup anymore (we're a "small business" with big dreams) but we are still indie. We've seen trends come and go. We just do what we do, knowing the tradeoffs, and plan to keep getting better as long as we can.&lt;/p&gt;



&lt;h2 class="wp-block-heading"&gt;Links&lt;/h2&gt;



&lt;ul class="wp-block-list"&gt;
&lt;li&gt;&lt;a href="https://chriscoyier.net/timeline/"&gt;Timeline – Chris Coyier &lt;/a&gt;&lt;/li&gt;



&lt;li&gt;&lt;a href="https://front-end-fire.com/episodes/115/"&gt;115: Adam Argyle on Cracking the 2025 Web Dev Interview | Front-End Fire&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;



&lt;h2 class="wp-block-heading"&gt;Time Jumps&lt;/h2&gt;</description>

Were over 13 years old as a company now. We decide that were not a startup anymore (were a small business with big dreams) but we are still indie. Weve seen trends come and go. We just do what we do, knowing the tradeoffs, and plan to keep getting better

We're over 13 years old as a company now. We decide that we're not a startup anymore (we're a "small business" with big dreams) but we are still indie. We've seen trends come and go. We just do what we do, knowing the tradeoffs, and plan to keep getting better as long as we can.



Links




Timeline – Chris Coyier  



115: Adam Argyle on Cracking the 2025 Web Dev Interview | Front-End Fire




Time Jumps

413: Still indie after all these years

The CodePen team talk about the ins and outs of running a web software business.

CodePen Radio

Details

Recent Episodes