Can iframes be annoying-free?

February 17, 2014

Heads up! This blog post hasn't been updated in over 2 years. CodePen is an ever changing place, so if this post references features, you're probably better off checking the docs. Get in touch with support if you have further questions.

We love iframes. They are a beautiful clean slate that allows us to allow you to author code into them and build all the awesome things you build. We also love to shrink them down and display a bunch of them in a grid so you can see real, live, beautiful previews of Pens.

But we need to be careful about making those iframes as non-annoying as possible. Here's just some of the stuff that we do, in some cases:

Stop animations and loops after a certain period, so you can get a flavor of the Pen but not overwhelm your computer.

Prevent autofocusing inside them to avoid awkward page scrolls.

Prevent autoplaying of various media.

Prevent them from changing the URL on you, which is dangerous as well as annoying.

Still allow target="_blank" links the best we can.

Allow them to be scrolled on all devices.

That's not even a complete list, so you can see how this iframe business is tricky. The are great, but loads of work.

Fortunately, the sandbox attribute of iframes helps a good bit with this. Perhaps it's most valuable ability is preventing top level location changing, which is hard to stop otherwise since there are essentially infinite ways to do it. Here on CodePen, we use sandbox, but augment it with quite a bit of our own code to do more security and annoying-ness prevention, including make things that sandbox already covers more robust.

However, we feel like there is more the browser could be doing to make iframes even better. Most of it has to do with making them annoying-free and security. In talking with some other industry folks (e.g. Mike West and Paul Irish from Google), it seems like most of our ideas would be alterations of sandbox.

So our proposal would be:

Disallow any browser-level popup if the sandbox attribute is present. I'm not sure if this is a complete list, but: alert, alert1, confirm, prompt, the one from window.onbeforeunload, and the one from .htpasswd. allow-modals would re-instate this ability.

Disallow autoplay of any kind. Right now things like <video> and <audio> are prevented from autoplay, but if you dynamically create one of these things, that can have autoplay to circumvent this restriction. Flash can also still autoplay. allow-autoplay would re-instate this ability.

Disallow audio of any kind. There are rather lots of ways for a browser to make sound, so rather than identifying all of them and fighting against each one individually, perhaps the browser could somehow cut the cord on it's ability to make sound out of an iframe whatsoever. allow-audio would re-instate this ability.

Disallow iframes from containing other iframes. The iframe attribute is already "transitive" in such that a child iframe can't be less strict that one above it. That's good, but doesn't quite solve all issues. Say you're trying to prevent alerts, so you overwrite it like window.alert = function() {};. That will stop them, unless within that iframe they make another iframe, giving a fresh window context, in which to alert from. This might not be needed if browser-level popups are able to be stopped. allow-iframes would re-instate this ability.

This is all inline with the idea that the sandbox attribute alone is supremely restrictive and you need to specifically allow more abilities.

We've brought this up on the WHATWG mailing list, so you can follow there starting at this message and going forward with the Next Message links.