So, I'm trying to find an answer to why this problem is happening; I've fixed the problem, but I want to know why it happened.

TL;DR

Google-provided conversion tracking code that injected an iframe using document.write suddenly caused the page to cease to execute in all versions of Internet Explorer, but was remedied by injecting the same iframe using a non-document.write method.

The Story:

Doubleclick is an advertising network that provides a JavaScript snippet to track conversions from ads.

The snippet they give looks like this:

<SCRIPT language="JavaScript">
var axel = Math.random()+"";
var a = axel * 10000000000000;
document.write('<IFRAME SRC=";src=143;type=donat01;cat=indir4;ord=1;num='+ a + '?" WIDTH=10 HEIGHT=10 FRAMEBORDER=0></IFRAME>');
</SCRIPT>
<NOSCRIPT>
<IFRAME SRC=";src=143;type=donat01;cat=indir4;ord=1;num=1?"
WIDTH=1 HEIGHT=1 FRAMEBORDER=0></IFRAME>
</NOSCRIPT>

Now, I know that, for all sorts of reasons, document.write is hazardous and should be avoided. But, Google is giving me this code, so, I figured I could trust it.

It suddenly started breaking all of our pages for all users using Internet Explorer. As in, the page would stop rendering entirely once it hit the document.write. This was crazy: One of the largest third party advertisers on the internet had given me JavaScript that had LITERALLY broken my purchase pages for 25% of my traffic!

As triage, I quickly substituted in the same code using the injection technique found in Google Analytics:

var iframe = document.createElement('iframe');
iframe.src = //the URL;
iframe.width = 0;
iframe.height = 0;
iframe.frameborder = 0;
var ref = document.getElementsByTagName('script')[0];
ref.parentNode.insertBefore(iframe, ref);

This resolved the problem, without actually explaining:

Why does a nearly empty iframe, injected using document.write, break Internet Explorer, but this method above doesn't?

So, I'm trying to find an answer to why this problem is happening; I've fixed the problem, but I want to know why it happened.

TL;DR

Google-provided conversion tracking code that injected an iframe using document.write suddenly caused the page to cease to execute in all versions of Internet Explorer, but was remedied by injecting the same iframe using a non-document.write method.

The Story:

Doubleclick is an advertising network that provides a JavaScript snippet to track conversions from ads.

The snippet they give looks like this:

<SCRIPT language="JavaScript">
var axel = Math.random()+"";
var a = axel * 10000000000000;
document.write('<IFRAME SRC="https://fls.doubleclick.net/activityi;src=143;type=donat01;cat=indir4;ord=1;num='+ a + '?" WIDTH=10 HEIGHT=10 FRAMEBORDER=0></IFRAME>');
</SCRIPT>
<NOSCRIPT>
<IFRAME SRC="https://fls.doubleclick.net/activityi;src=143;type=donat01;cat=indir4;ord=1;num=1?"
WIDTH=1 HEIGHT=1 FRAMEBORDER=0></IFRAME>
</NOSCRIPT>

Now, I know that, for all sorts of reasons, document.write is hazardous and should be avoided. But, Google is giving me this code, so, I figured I could trust it.

It suddenly started breaking all of our pages for all users using Internet Explorer. As in, the page would stop rendering entirely once it hit the document.write. This was crazy: One of the largest third party advertisers on the internet had given me JavaScript that had LITERALLY broken my purchase pages for 25% of my traffic!

As triage, I quickly substituted in the same code using the injection technique found in Google Analytics:

var iframe = document.createElement('iframe');
iframe.src = //the URL;
iframe.width = 0;
iframe.height = 0;
iframe.frameborder = 0;
var ref = document.getElementsByTagName('script')[0];
ref.parentNode.insertBefore(iframe, ref);

This resolved the problem, without actually explaining:

Why does a nearly empty iframe, injected using document.write, break Internet Explorer, but this method above doesn't?

• javascript
• html
• internet-explorer
• document.write

• 11 Probably because you shouldn't be using document.write, iframes, or Internet Explorer :) – jtbandes Commented Jul 3, 2011 at 4:41
• Couldn't agree more on all three counts :) Sadly, 25% of my audience uses IE, and this document.write iframe code is used WIDELY on the internet, but this problem does not appear to be otherwise documented, AFAIK. – Yahel Commented Jul 3, 2011 at 4:46
• 3 Oh, please. Internet Explorer completely breaks itself. – Lightness Races in Orbit Commented Jul 5, 2011 at 14:12
• 1 @TomalakGeret'kal this is the tracking code for Doubleclick floodlight tags. Some variation of this tag appears on 14.5% of the top 10,000 websites. trends.builtwith.com/ads/DoubleClick.Net Though there are a couple of variations, this is the most widely used. – Yahel Commented Jul 5, 2011 at 15:17
• 2 @TomalakGeret'kal well, I couldn't agree more on that count. – Yahel Commented Jul 5, 2011 at 19:53

6 Answers 6

I've solved the problem; it turns out that it had nothing to do with the contents of the <iframe>.

It turns out the page is served by a framework that began using a backend DOM parser that, for reasons likely related to the presence of </ within a <script> tag within the document.write, completely removes the </iframe> closing tag from the generated page, even though it preserves it in the backend. (It's probably trying to enforce ETAGO rules).

The reason I was able to reproduce it was because I was copying the generated document.write code, not the original code, and never noticed the missing </iframe>. (And my "functioning" document.write code didn't have the stripped out </iframe> tag, leading me to believe that the problem was the contents of the iframe.)

As a result, browsers parsed an unclosed <iframe> tag on the page, which Internet Explorer didn't know how to handle, and died part way through the parsing of the iframe (I'm still not totally sure why).

document.write() blocks further page rendering until it finishes. I assume that the remote script was taking a while to load, and thus blocking the rest of the page from loading.

I also assume that Math.Random() function doesn't help matters.

Also...Google's tracking codes scare me...they tend to be ugly hacks of javascript.

There is 2 reasons why the first method should be slow.

• document.write() blocks until it is actually performed
• the window’s onload event doesn’t fire until all its iframes, and all the resources in these iframes, have fully loaded

Your solution works because the iframe it creates does not request the remote url until after the onload event. Having a set timeout on the first code, you would also get the page to load, then the request to the remote url to fire.

As to why the change of code broke the site, I can not seem to find any speed differences transferring between the two. Maybe it seemed faster because it was cached.

I don't know about the structure of your site, but normally the first script tag is in the <head>. An iframe in the <head> wouldn't be rendered. I'll wager if you did document.body.getElementsByTagName('script')[0] you would probably have similar issues to the one you described above.

Seems you're having a similar problem that I had several months back. The document.write triggers, and overwrites the page. Just use the iframe directly, and everything should be kosher.

I tried replicating your issue but couldn't on IE9.

Either I don't have the right test setup or it seems IE prior to IE 9 had some bug. Firefox had a simialr bug: https://bugzilla.mozilla.org/show_bug.cgi?id=293633

Maybe its a combination of unclosed iframe and something inside the page that's being rendered.