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. Jon Says:

    You might find this article from microsoft interesting:

    I ran into the same problem when using the flash UFO javascript library, we still haven’t fixed the problem…

  2. Delapouite Says:

    Each time I was reading the mootools forum, I felt like I was the only poor guy who encounter this IE critical error again and again.

    Good to see that others people are also confronted with this annoying issue. One workaround that I experimented, is to put the javascript (and the domready function) at the very bottom of the page, after the closing instead of between tags. But of course it isn’t very elegant.

  3. Fardeen Says:

    Thx a lot ! IE make me crazy !

  4. Aaron N. Says:

    Jon, thanks for that article. At least they admit it:

    Microsoft has confirmed that this is a bug in the Microsoft products that are listed in the “Applies to” section.


    • Microsoft Internet Explorer 5.5
    • Microsoft Internet Explorer 6.0
    • Windows Internet Explorer 7

    This is kinda what I thought was going on, but it’s messed up that IE just shuts down the page instead of throwing a javascript error. I’ll edit this post and add your link and more detail. Thanks again.

  5. Jesswa Says:

    “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.”

    So why does the last example work…???

  6. Aaron N. Says:

    To be honest, I don’t know, but it does.

  7. Justin Says:

    I can’t decide what’s worse; this bug, or that Microsoft has let it drag out over the course of 3 major releases. IE is a joke. It’s practically criminal that they’ve foisted it on the unsuspecting public.

  8. Rasmus Says:

    Thx, Aaron! I’m going nuts over this error.

  9. CSS, JavaScript and XHTML Explained » Including Javascript in XHTML: external, DOM created, CDATA & comments Says:

    […] If you are effecting the DOM during page load, and use innerHTML = “string…” after you do it, Internet Explorer erroneously retroactively-prematurely closes the DOM. Either avoid using innerHMTL, or don’t modify the DOM until the page is fully loaded (or, better yet, avoid both). See IE and Operation Aborted for more info on this special IE quirk. Spread the love & knowledge: These icons link to social bookmarking sites where readers can share and discover new web pages. […]

  10. Pamps Says:

    Great article!
    I also was trying to find this info cause IE was broking all the time and i could not figure why. Now i have the explanation.

    In fact i´m not a coder so will not be able to resolve using elegant ways but used Delapouite tatic to resolve.


  11. Diego Perini Says:

    Jesswa, the last case shouldn’t work in any IE and it does not in my case.
    (Emualated Windows XP SP2 IE 6.0.2900.2180) so a slower machine…

    If you don’t get “Operation Aborted” from that test we have different results. I may be wrong and I am going to retry it tomorrow (fresh).

    The reason it “should fail” is that the scripts are modifying a place in front of them by appending to the BODY (which is still an open node) and while the insertion point you need does not exists yet, remember that these scripts are executed in-line…

    In most occasions if you have to append a “js widget/extension” to the page you don’t need to append the container it at the end of the document, so use insertBefore instead of appendChild where feasible.

    If you absolutely need to append at the end of the document you would better use a good DOM function to to that when the document is completely loaded to avoid this nasty bug of IE.

    There have been no reports about this BUG on other browsers that I am aware, however it seemed wise to me to avoid that even in other browsers, I can’t test them all, I feel like this part has been a pain in the implementation for those who wanted to make this possible.

    Aaron can you confirm that the last case does not breaks on IE6 ?

  12. Aaron N. Says:

    Hi Diego,

    First, I am ok with the notion that appending a child to a node that isn’t closed should be illegal. What’s aggravating is that IE then discards the page. When you get the error YOU CAN SEE THE PAGE, then, you click “OK” and you get that lame 404 page they have. Debugging this is time consuming as the few debugging tools we have for IE are useless. That’s my issue with it. It should throw an error like any other javascript error and help you fix it, but otherwise display the page.

    Regarding that last test, you are correct, it does not work. The example set I was working with when I wrote this two months ago had some of this in a domready event (see Mootools) so I’ll have to go dig it up again…

  13. Aaron N. Says:

    …still looking for the file, I remember what the details were at least. Our IframeShim class was instantiated on domready. This worked fine. But we had another script in the page body that did document.getElementById(‘id’).innerHTML = “string” and this caused domready to fire early…

  14. Diego Perini Says:

    thanks for confirming that the last test also breaks in IE, I wasn’t able to reproduce, even not with a real Window…

    So we agree and are hopefully clear on open nodes…

    Another point is that “domReady” as other “DOMLoaded” functions fail in detecting the page loading timings in situations where there are no images for example (a barebone HTML test case).

    Probably the culprit being the the document.write trick used in those functions in that precise environment (no images, no style sheets, no external resources) and as in your tests above.

    Now we need some test that shows that is indeed possible to modify the DOM if the desired modification point is behind the in-line execution point, to test change:




    and all samples will work.

    The difference beeing the new node is inserted at the top of the body instead of beeing appended at the end. That may be adjusted with absolute positioning (CSS).

    Appreciate your thoughts on this since it is an hot issue for me
    and I am still open to change my mind :-)

  15. Stephen Says:

    Thank you. I thought I was the only idiot in the village with this error.

  16. CereS Says:

    I’ve lost hours trying to find out the way to avoid this error.

    At last I’ve found that the only way to bypass this bug is something like:
    var load_method = ( ? ‘load’ : ‘domready’);

    And change all “domready” with load_method.

    e.g. (Slimbox):
    window.addEvent(load_method, Lightbox.init.bind(Lightbox));

    In this way IE users will see the page and people using Firefox or Opera will take advantage of the onDomReady method!

    The only other solution is to eliminate explorer from every PC on the earth… Ain’t this easy :(

  17. Diego Perini Says:

    the “domReady” function is a pain, randomly
    I have seen it fail in the following cases:

    – if using innerHTML
    – if using document.write in the BODY
    – if the page doesn’t contain images at all
    – if the total size of images is less than the page size
    – if you have additional “deferred” scripts in the page
    – sometime randomly if using the F5 key to refresh the page

    don’t you think it’s time to have a new “domReady” function instead
    of forcing people to go back to the slow “window.onload” event ?


  18. Aaron N. Says:

    @Diego, you write that as if I’m responsible for this code or something. I didn’t author it; I just blogged about it. Mootools has a domready function that has been pretty stable for me (this page uses it, for example). If you aren’t happy with the code that others have written, you are free to write your own.

    In my experience, this error is encountered when one writes code that tries to do things before the page is ready – inline javascript or something like that. You should avoid document.write entirely. You should avoid innerHTML entirely (and use things like Mootools setHTML method to avoid memory issues). I haven’t authored a page without an image in ages, so I can’t speak to that problem.

    @CereS, I don’t like using onload for IE just to get around this problem. I’ve authored tons and tons of javascript and only rarely do I encounter this issue. If you write your code well you shouldn’t either. It’s annoying and difficult to debug, but you CAN do it if you want to.

  19. ZeN-Guardian Says:

    Great solution, it works perfectly, now my website works in IE6 and 7 while using Slimbox and the Google’s Urching jasvascript.

    I don’t mind having to modify one line and add another to a .js file as long as a website can be seen. It does have a small flaw where the page has to load completely if the user wants to experience the cool effects of slimbox, but I’m willing to pay that little price (knowing that the users will still be able to at least the first image) then having to remove a good feature because IE6 and 7 don’t know how to handle a .js correctly.

    Thanks again CereS.

  20. Diego Perini Says:

    @Aaron, sorry if I made you feel responsible, I was just referring to what you said above about domready:

    >The example set I was working with when I wrote this two months ago had some
    >of this in a domready event (see Mootools) so I’ll have to go dig it up >again…

    I now understand why you had problems with the above tests…

    >If you aren’t happy with the code that others have written,
    >you are free to write your own.

    Hey !!! I am happy with all the code people write, so I can bug them.
    Don’t take that so personal, you haven’t wrote that yourself…
    As you said it is still useful for your site.


    PS: just to let you know…there are good alternatives to the defer method
    used in the domready function…

  21. Pixy Misa Says:

    Thank you!!!

    I spent a couple of hours cursing at this, then finally dug up this page. All I needed to do was move one script from the top of the page to the bottom, and everything is happy again.

  22. IE7 operation aborted - ASP.NET Forums Says:

    […] Hi there.Everytime I try to open a modal Window programmaticaly by doing:String script = "radopen('PopUp/TrainingDetailsEdit.aspx',null);";ScriptManager.RegisterClientScriptBlock(this, typeof(Page), "OpenPopUp", script, true);in the code-behind, IE7 fires an operation aborted error. I tried this with Telerik RadWindow as well as Telligent_Modal modal scripts. Does anyone know how to accomplish that correctly? I can´t open it straight away as I need to process some things before opening the page. It works well in other Browsers but not in IE!There is a nice article about this issue here -> operation aborted articleAll the best,Elmar […]

  23. Carlos A Says:

    Thanks this article has solved my problem!!!!

  24. Bounder Says:

    No solutions, but I narrowed my issue down to the Inline MP3 player plugin ( on my WP installation.

  25. leo Says:

    hey everyone,
    got the same problem with slimbox.
    my solution:
    i have an empty div (id = helper) at the very top of my .
    in the javascript i grabbed my helper-div ($(‘helper’)), saved it to this.helper and replaced all document.body references with it.

    this actually works fine in IE 6 & 7.

    just one small flaw (besides the extra container […]): you have to tune the slimbox.css with some z-index values if you are using absolute positioned elements on your page.

    maybe this is useful to someone.
    best regards from germany – leo.

  26. Aaron N. Says:

    is this the clientside version of slimbox? One thing we’ve noticed here is that there are some circumstances (esp. when used with innerHTML) that cause IE to fire domready prematurely…

  27. eclaudius Says:

    I implemented a kind of lightbox called Moodalbox, based on Mootools. I got the same error on one of my websites, the others worked just fine. Moving the script tag containing the link to moodalbox.js to the bottom of my html-page seemed to bypass the problem. It’s not an elegant solution indeed, but it saves me hours of going through html/javascript. Thanks for everyone’s contribution on this forum!

  28. Louisa Says:

    um hi, i know this makes me sound really stupid but i don’t really understand what you guys mean about the child and parent thing but I’m trying to get onto a website and the ‘Operation Aborted’ thing keeps happening. What’s weird is the website was working fine…right up until it wasn’t. Could you explain to me in English (no big techincal words) what to do to fix it?
    Much appreciated.

  29. Aaron N. Says:

    Hi Louisa,

    Yes, there is an easy way to fix it: use Firefox. This problem is difficult for those of us WRITING web sites because we have to support IE6. But if you encounter a site with this problem and you want to see the page, just don’t use IE6. Upgrade to IE7, or install Firefox (which is my recommendation).

  30. bluedee Says:

    I also got this problem especially in using IE7. I have to refresh my page to see the correct result. Fool microsoft

  31. Gregory Magarshak Says:

    I’m running into it too.

    I have MooTools. And I am trying all sorts of ways to inject FLASH into IE with javascript.

    MS disabled it because they didn’t settle the Eolas patent.
    But the javascript seems to cause Operation Aborted – also MS’ fault. THANK YOU GUYS! How am I supposed to have active Flash content AND mootools? Cn anyone tell me? :-/

    sheesh, I can’t *BELIEVE* IE7 has this error.

    Anyway, I have two comments to make:

    1) Why use DomReady, when you can use document.onload? It occurs after DOMReady, doesn’t it? And it works for every page on every browser.

    2) That said, that’s exactly what I tried. I had tried containerdiv.innerHTML = stuff in the body.onload event and guess what:


    I wish I knew how to get rid of this insiduous error. GRRRR


  32. Adam Platti Says:

    So, one thing that nobody else seems to be writing about, are when the script can not simply be place at a different spot in the document because it has a document.write() call that is expected to execute at the spot in the document where the output belongs.

    Specifically, I’m talking about ADS!

    It’s kind of hard for me to believe that nobody else has come across this problem yet, but most of the solutions I read about say “just move your script”, or “just call your script after onload”.

    I’m still working on a solution for us, but one idea we have is to put the script tag for the ad at the end of the document, right before the tag. Right before the script tag, though, set document.write to be a function that does an innerHTML to a specified DIV instead of doing a normal document.write call().

    Basically in theory it’s this:

    document.write = function(html){ $(“ad-div”).innerHTML = html; };

    Not sure if it will work yet….

  33. Adam Platti Says:

    sorry, didnt HTML escape my tags in my example:

    <script> document.write = function(html){ $(“ad-div”).innerHTML = html; };</script><script src=”—AD URL–“></script></body>

  34. Aaron Newton Says:

    document.write doesn’t create this problem. the reason you don’t see us complaining about ads (we certainly have our share at CNET!) is because most of them use doc.write and this isn’t the problem. The problem is dom injection (innerHTML, appendChild, etc.).

  35. Adam Platti Says:

    Humm, I’m pretty certain that we are seeing this problem when ads are inserted, and they are definitely using document.write. Perhaps it has to do with flash ads. I’ll write back when we figure it out.

  36. Aaron N. Says:

    Note that if they doc.write *other* scripts that contain dom injection methods, that might do it. But the whole point of doc.write is that the dom is still being drawn. It’s an evil practice, and I hate the ad companies for it. That said, ad companies indirectly pay my salary, so, well, what are ya gonna do?

    If you do manage to get a test working the reproduces this error WITHOUT dom injection, I’d be very interested to see it.

  37. Patrick Grinsell Says:

    I’ve found, oddly enough, that the most reliable way to eliminate this problem is to run potentienally offending script in a setTimeout. For example: setTimeout(“init_script()”,0). Note that the timeout is zero so it doesn’t actually wait. What is interesting to note, though, is that none of the functions initialized using setTimeout start UNTIL THE DOM IS COMPLETE. I’ve tried many other methods and although this kinda seems like a hack it’s the only one that gives me truly reliable cross browser results with a minimum of fuss.


  38. Aaron Newton Says:

    It’s generally bad form to use setTimeout to evaluate strings, much the same as using eval() is. I’m not sure if this solution does fix the problem in all cases, but the practice is not very clean, in my opinion.

    Still, coding for IE6 rarely results in clean solutions when one encounters these types of errors, so if it works for you, I’m not going to condemn you to hell or anything. In general though, I strongly recommend against using setTimeout with strings.

  39. Chris Says:

    This took me a while and reading the same 10 or so threads dealing with the issue hoping that i could find that answer without having to go to microsoft… but alas, i had to return to the belly of the beast for the solution. and to make matters worse, it was easy.

    lousy microsoft.

    I am implementing a version of slimbox using mootools 1.11 and getting the same error in IE7. I tried the defer=”defer” trick, nope. Tried the windows.AddEvent(‘domready’, function(){… nope.
    frustration set it. for about 5 hours.

    turned out that the code snippit that initializes Lightbox needs to be placed with the parent as only after the element has been loaded.


    Lightbox.init({descriptions: ‘.lightboxDesc’, showControls: true});

    in other news… IE8 passed the acid 2 css rendering test. unfortunately we all need to purchase the newly patented Microsoft Acid 2 Monitor Goggles in order for it work.

  40. Aaron N. Says:

    You might check out our copy of Slimbox, a Lightbox clone for Mootools:

  41. Mokaddim Says:

    I got a solution. You have to use onload of body. nothing else.
    see this. ieoperation-aborted-solution

  42. Aaron N. Says:

    The issue here is that window.onload (aka body.onload) is that it occurs after all the assets have loaded – images, flash objects, etc. – while domready fires as soon as the dom is built. The IE problem occurs when our domready methods are executed too soon, which seems to sometimes happen when you use other dom manipulation methods within the dom itself (document.write, other javascript that attempts to manipulate dom elements that are loaded before the body has closed).

    Using window.onload will solve the problem, that’s true, but now you must wait for EVERYTHING on the page to load – every image – which means your dynamic navigation and login boxes and whatnot are inoperable until those assets load, which may be well after the user can see the page and wants to interact with it.

  43. Bob Says:

    Let throw a new wrinkle in here… I too am getting the Operation Aborted error and after numerous hours of stripping out JavaScript and Flash have narrowed “my” issue down to one trigger:

    If I comment this out the page loads without error – consitently and put it back in and it gets the Operation Aborted error >80% of the time. A potential uniqueness of my situation is that the page is within an iframe.

    I have no idea if this tidbit helps anyone but judging by the variety of circumstances in this forum and others, there is no single clear cut solution. Certainly none that work for my case.

  44. Bob Says:

    Unfamiliar with including code here but I was referencing:
    meta http-equiv=”Content-Type” content=”text/html; charset=ISO-8859-1″

  45. Christopher Crooker Says:

    I had a slightly different problem, but this article lead me to the answer so in case someone else finds this the same way:

    <div id="example" />
    $(‘example’).innerHTML = ‘example’;

    The self-closed tag was the culprit. No idea why.

  46. Diego Perini Says:

    When nothing else work on IE, use my doScroll(“left”) hack:

    This will solve the IE “onload” problem in a standard document,



  47. bvls Says:

    I have one question:
    Does konqueror give similar problem like IE?

    I wrote a code using Mootools 1.2b with 1.11 compatibility on, which works fine in FF, but comes blank with IE and Konqueror.
    I have no clue of the reason behind. But this discussion throws some light
    on the ‘potential reason’.


  48. Whisller Says:

    Thanks you very mutch! You saved my life :) Thanks!

  49. Jubz Says:

    Very helpful blog post. Helped me find the cause of this problem in my web application. Moving most of my JS script calls to a function that implements window.onload was the magic. I had them all over my JSPs, and when you have deep clauses, its trouble.

  50. IE Says Internet Explorer cannot open the Internet Site ________. Operation Aborted. I Say WTF? Says:

    […] Click here to read Aaron’s full post. The moral of the story is not to modify elements that haven’t fully loaded! addthis_url = ‘’; addthis_title = ‘IE+Says+%22Internet+Explorer+cannot+open+the+Internet+Site+________.+Operation+Aborted.%22++I+Say+%22WTF%3F%22’; addthis_pub = ”; […]

  51. 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.

  52. Peter Says:

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

  53. Aaron Newton Says:

    Easy. Use Firefox.

  54. 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…

  55. 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.

  56. 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 ?

  57. [email protected] Says:

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

    tips from this website: