How Google +1 Widgets "Break Out" of their IFRAMEs | Hacker News Reader

How Google +1 Widgets "Break Out" of their IFRAMEs

stackoverflow.com

112 pointsalanh11 comments

  <script type="text/javascript" src="https://apis.google.com/js/plusone.js"></script>

Given this is the code you paste on the page I think it is pretty obvious to anyone who bothers to look.

The CSRF information is great however!

Google +1 widgets don't "break out" of their iframes. They're not in iframes in the first place.

As the first SO response points out, the widget is JavaScript code that runs in the host page, so it can easily create and manipulate any kind of DOM element anywhere in that page. Of course there may be iframes among those elements, but the JS code isn't limited to that.

They are in <iframe>s. Just not one <iframe>, and the code is not originally included via <iframe>.

But yeah, since it creates the illusion of breaking out, the submission title has the phrase in quotes.

That's right, the bulk of the gadget may run in one or more iframes. I just meant that they do load a script element into the host page.

Once you do that you can do anything to the page, and you can also use one of several methods to have this script communicate with scripts inside the iframes that it creates.

Another advantage of using an iframe (besides cross-domain communication) is that you don't have to reset every CSS style you need. When you insert JavaScript into a page it inherits all the crazy CSS already on the page which can cause all sorts of problems. Iframes have their own context and give you an easy way to avoid that problem.

Yup.

Interesting tidbit: HTML5 suggests the `seamless` attribute for <iframe> elements, which would cause those CSS styles to actually affect the contents of the <iframe> (and some other changes, like links affecting the location of the parent window). http://www.w3.org/TR/html5/the-iframe-element.html#the-ifram...

(Of course, you meant to say “when you insert typical content DOM nodes”, not “insert Javascript”.)

that is what I meant to say. thanks for clarifying.

An iframe also helps in IE6 (can't directly remember if it's also in IE7) to draw overlays over form elements, otherwise they will be on top.

Related: if you're only using the iframe for the CSS reset, you can also just document.write its contents, so the client doesn't need to do a separate request and the iframe is on the same origin as its parent frame. Example: https://github.com/cappuccino/cappuccino/blob/master/AppKit/...

Although one major disadvantage I've discovered recently is that if you embed an iframe (with a no-cache response header, i.e. Facebook's like button) it stops Firefox adding the page to the back-forward cache. Same with Webkit if the protocols don't match. https://developer.mozilla.org/en/using_firefox_1.5_caching

I wonder how much extra bandwidth Facebook has wasted worldwide by doing this? Twitter allows caching for 30 mins at least, good enough for back/forward caching to be useful.

Twitter and Facebook also have script tags sitting on most websites so technically those scripts could do whatever they wanted to your page. I believe it's possible, however, to create LIKE and TWEET buttons using direct iframe tags with no need for a lib. That's the method i prefer.

Reply on news.ycombinator.com