IE and “Operation Aborted”

Wednesday, April 4th, 2007 @ 4:48 pm | filed under: Browser Bugs, Manipulating the Dom

Internet Explorer‘s behavior sometimes really, really makes me angry.

We recently rolled out a copy of our javascript libraries after much testing and, a few hours later, discovered a page on our site that IE was barfing on. Specifically, the page would load about half way and then announce that it could not load the page (despite the fact that it’s clearly loaded behind the error message) and then present you with its generic “page not found” content.

I’ve seen this behavior before and generally know what to look for, but it’s a huge pain because the page is gone and your only method for debugging it is to slowly remove code, line by line, until it stops doing it. Then you put things back bit by bit until you narrow it down to the offending line. It’s painstaking work and the constant error popping up begins to really grate.

So why does IE do this?

Perhaps I should use “when” instead of “why” in that header, because I don’t really know why the developers of IE would do this.

Update: Bit thanks to Jon in the comments for turning me on to this MSFT support page about this topic. I’ve updated this article here to more accurately describe the problem. More detail can be found in the MSFT article.

IE does this when you attempt to modify a DOM element before it is closed. This means that if you try and append a child element to another and that other element (like the document.body) is still loading, you’ll get this error. This will occur if you use .appendChild (which in Mootools includes .adopt, .injectInside, .injectBefore, etc.) or if you use Element.innerHTML = “” (or in Mootools, the .setHTML method).

The general rule of DOM manipulation is that you can’t mess with it until it’s loaded, which is why we use the domready event (this is not a native event, but most frameworks have some method for creating this event). In Mootools, you do it like this:

[js]window.addEvent(‘domready’, function(){
//DOM code…

The exception to this rule is that you can modify the DOM that’s loaded so far if you do it inline. In other words, you can’t modify the DOM before it’s loaded, but you can modify the portion of the DOM that’s loaded at any given point. For example, you could have this and it would work:



Because you are executing this code after the DOM element is loaded, it’s ok.

…except when it’s not.

What I found today was that a Class I’d written long ago (IframeShim) created a conflict of sorts with this general rule (the rule that you can alter DOM elements that have already loaded, even if the page hasn’t finished).

IframeShim puts a hiden iframe under an element to hide things below it (like select lists; see the link above for more detail). Previously, I inserted the iframe into the DOM right after the element that it was shimming:

[js]var iframe = new Element(‘iframe’);
//…some more stuff to format it

I recently changed this because if the parent element of the one you were shimming had CSS properties that cascaded to its children, the iframe, which is positioned absolutely, would inherit margins and padding and it would throw off the positioning. Instead, I needed to inject the iframe into the document body:

[js]var iframe = new Element(‘iframe’);
//…some more stuff to format it

This code on its own worked fine (and passed our QA process). Here’s where it gets bizarre (perhaps not, as this sort of thing is almost normal in IE).

The document that was breaking (the “Operation aborted” message) had in it a line like the first example above:



This is an over simplified example, but when I removed all the other code it was the innerHTML = “something” that was the culprit.

If I removed that line, the page worked. The thing is, the only thing that changed was our library (which has a LOT of stuff in it). So how did that change suddenly make this innerHTML = “something” become so destructive?

So then I started removing chunks of the library until I found that it was the IframeShim class, which I had recently changed. This led me to the change I mention above, where I append the iframe to the document.body.

It would seem that IE is ok with adding something to the document body at any time, but if you use innerHTML = “string…” after you do it, you’ll somehow retroactively-prematurely close the DOM or something. That is messed up.

Anyway, it took me a day to figure all this out and make it so that IframeShim won’t append the element to the DOM until it’s ready (in IE) and fix the bug.

After reading the MSFT support article, it’s apparent that this behavior isn’t quite explained by it. According to the article, you’ll get this error when you try and inject content into a dom element that isn’t closed. Their example:

This problem occurs because a child container HTML element contains script code that tries to modify the parent container element of the child container. The script code tries to modify the parent container element by using either the innerHTML method or the appendChild method.



According to MSFT, this error will occur because you are trying to modify the before the is closed. Using the onDomReady event would solve this problem here. But in my problem that I worked out above, I append something to the before it’s loaded, but IE doesn’t complain. It only complains when I have that AND a innerHTML=”something” line on the same page. The line that uses the innerHTML=”something” isn’t referencing a tag that is still open, though the IframeShim is. It’s like trying to diagnose why opening the gas cap on your car makes the hub caps fall off. They aren’t connected.

This breaks


This doesn’t break


This doesn’t break



Microsoft, please make better browsers (note that IE7 has this problem, too).

57 Responses to “IE and “Operation Aborted””

  1. Vasu Says:

    i am a novice user, could you let me know how to fix the operation aborted error. on my other pc, it is working fine.

  2. Peter Says:

    This is ridiculous. How the hell can I change the scripts on or when they’re giving me this error??

  3. Aaron Newton Says:

    Easy. Use Firefox.

  4. omancipator Says:

    Huge thanks to BOB for his note about the meta tag…NEVER would have suspected that the meta tag was the culprit, but that ended up being the culprit on our site as well…

  5. gav Says:

    Aaron et al, a very informative blog thankyou. I have also been gnashing my teeth at this problem and relieved to find a solution. Except, what do I actually have to do to implement it? I am using the Calendar script ( and insert/call my javascript as follows in my page :

    window.addEvent(‘domready’, function() { myCal1 = new Calendar({ date: ‘d M Y’ }, { direction: 1, tweak: { x: 20, y: -30 }}); });

    Can anyone advise me what to do which will allow use of the Calendar script in IE without the “Internet Explorer cannot open the Internet Site ….. . Operation Aborted” problem?

    Thanks in advance.

  6. coupon Says:

    I’am getting this error too “operation aborded” then i have using this code

    window.onload = function(){

    all is ok now, but i must wait that all the webpage is loaded for javascript execute my script…

    Is there any other way ?

  7. [email protected] Says:

    this method works for my slimbox issue
    just shift javascript to before

    tips from this website: