What Happened to Operation Aborted?

Have you ever seen this dialog while surfing the web in Internet Explorer?

A screen shot of Internet Explorer 7 with a dialog superimposed with the text: Internet Explorer cannot open the Internet site. Operation aborted.

You browse to your favorite news site. The content starts loading, you’ve already started reading the headline, and then it happens. Those of you familiar with the operation aborted dialog know that it spells sudden doom for the website you’re currently viewing. Unsuspecting users have no idea what it means and simply click ‘OK’ and then watch in horror as the web page they were just reading disappears; only to be replaced by an navigation error screen. More savvy users move the dialog out of the way so that they can finish reading what was visible before they too accept the inevitable…

This dialog (and its side-effects) is gone in Internet Explorer 8 Beta 1.

What caused the operation aborted error?

The operation aborted dialog in Internet Explorer 7 is triggered by an HTML parsing exception that occurs when all the following specific conditions are met:

  1. The HTML file is being parsed
  2. Script is executing
  3. The executing script attempts to add, or remove an element from an unclosed ancestor in the markup tree (not including the script block’s immediate parent element).

You can see that each of these conditions is true in the following example markup:

   <script type="text/javascript">
var newElem = document.createElement('foo');

The HTML file is being parsed, and encounters a script block. The script block contains inline script which creates a new element and attempts to add it to the BODY (document.body.appendChild(newElem)) element before the closing BODY tag has been encountered by the parser. Note that if I removed the highlighted DIV element, then this problem would not occur because the script block’s immediate parent would be BODY, and the script block’s immediate parent is immune to this problem.

Unfortunately the operation aborted dialog was always thrown at the top-level of a web page, even if the problem occured in an iframe. In fact, in most scenarios that we encountered, ad injection in an iframe was usually the root cause of this error. After the user dismissed the error dialog, Internet Explorer would navigate away from the page.

What we did in Internet Explorer 8 Beta 1

Screen shot of Internet Explorer 8, with emphasis given to the status bar where a script-error indicator is present

In Internet Explorer 8, our goal is to change the behavior that previously caused the following problems:

  • The operation aborted error was a modal dialog. The dialog was not actionable by any user.
  • Dismissing the operation aborted dialog caused Internet Explorer to navigate to an error page. This prevented any potential debugging of the affected page.

When the HTML parser throws the operation aborted exception, rather than announce this error to the world, Internet Explorer 8 Beta 1 discreetly tucks this information away into the list of script errors associated with the webpage and stops parsing HTML and running script at that point. We also tried to provide a little more help to those developers who encounter this error (but don’t read the IE blog) by including the KB article number in the text that describes this problem:

HTML Parsing Error: Unable to modify the parent container element before the child element is closed (KB927917)

A simple web search for “KB927917” in major search engines will usually turn up the corresponding Knowledge Base article as the first hit. That article describes the specifics of this problem and available workarounds.

Interoperability observations and feedback request

It’s intriguing to observe the parsing behavior of various browsers in these situations, as it’s not universally consistent. For the scenarios involving adding elements to an open container (e.g., appendChild), the appropriate behavior seems very straightforward–just add the element. Future markup encountered by the HTML parser (after execution of the script block) should then be appended to the existing in-memory DOM. Other browsers tend to agree on this point.

In the case where a parent element is removed (e.g., removeChild, innerHTML, outerHTML) and parsing resumes, the big question becomes: what is the parser’s new context? Different browsers answer this question differently. By and large, most other browsers invalidate the parsed context from the point of deletion in the DOM, and “remember” what was deleted such that future parsed markup is ignored until the containing tree (now deleted in-memory) is closed. You can start to see the complexity in this approach, especially if the tree is not well-formed. On the other hand, other browsers take a different approach and “re-base” the parsing context of the current markup at the point of deletion. This results in future markup being inserted in “the wrong place” (a matter of perspective) in the in-memory DOM. For illustration purposes, consider the former as “approach A” and the latter as “approach B.” Given the following markup, what do you as web developers expect? I tend to think that approach A is the saner model to follow:

  <div id="container1">
    <span id="span1">First block of text</span>
    <script type="text/javascript">
    <span id="span2">Second block of text</span>
  <div id="container2"></div>

Final DOM tree constructed using each approach mentioned above:

Approach A

Approach B


What can you do?

In any case, the moral of the story is to avoid getting yourself into this scenario if possible. Granted, in some cases it may be inevitable, especially if the content is not under your direct control (like ad-injection scenarios). Knowledge Base article 927917 mentions some workarounds, but additionally to avoid the problem, you simply need to ensure that your script doesn’t meet all three of the conditions I outlined earlier. So, if possible, do the following to avoid an operation aborted error:

  1. Moving your script execution to a function that is invoked after parsing is complete (e.g., onload)
  2. Adding the defer boolean attribute to the script block (this defers execution of the script content until parsing is complete)
  3. Limiting your tree modifications to the script-element’s immediate parent
  4. Moving the location of your script block to a child of the body (this usually solves most problems, while allowing the most flexibility in terms of scenarios).

    Always a pleasure,

    Travis Leithead
    Program Manager
    IE8 Object Model

    Comments (77)

    1. Garry Trinder says:

      This underscores the importance of good UI text in errors and dialog boxes. Instead of OK, the button in the Operation Aborted should’ve been labeled Close Page or something like that to identify what the user was doing by clicking. And "Operation Aborted" ??? Any message would be better than that!

      Glad to see this improved in IE 8, thank you!


    2. rkpatrick says:

      I’ve seen this error quite a bit on MSNBC.com (always while reading articles coming from I believe Newsweek). I figured it was one of their Flash ads trying to redirect the browser to a bad URL. Good to know the true cause and the underlying reasons.

    3. Samuel says:

      There is nothing worse in a program than excessive modal dialogs. I cringe every time I use a program that shows more than one in a row.

      This is the kind of development strategy that may make IE once again a leading browser. I want see as much competition as possible.

      Down with modals!

    4. ZiggyFish says:

      This is why I use Firefox. IE just nags and fails to display the content properly on some websites I go to. Also the things I’m use to in Firefox don’t work on IE (i.e being able to _Google_ (not MSN search) when I type CTRL->K (usually I type CTRL-T CTRL-K to get a new tab and put the cursor at the top for a _Google_ search).

    5. George says:

      This was one of those… "OMG! I can’t believe they shipped IE7 with this not fixed!" things.

      I realize that the developer is effectively in error, but it was still a nasty error message

    6. Is there any mandated behavior of the browser in this specific case? I agree that the message box is probably one of the worst things you can do here and I ran into that a few times myself (on other websites, not my own code) and wondered what exactly triggered it.

      I can imagine this post spawns some useless bashing (it already has). And yes, approach A seems to be the better one. The question is whether settling on approach B (even though it exposes application implementation where it should not) might be better to follow if most major other browsers (well, there aren’t many) tend to use this approach. I see many people here criticizing the IE Team for doing things deliberately different than other browser vendors and thus hinder interoperability.

      Although, if the spec allows for it and one approach is clearly better than another (or neither) I don’t see a compelling reason to follow other implementations.

    7. Aah, forgot something: How will the proposed workarounds/solutions affect behavior in other browsers? (I. e. will those be an IE-only fix, then?)

    8. Icepick says:

      "More savvy users move the dialog out of the way" <- No, you don’t get it, "More savvy users" don’t use Microsoft Internet Explorer, so they are not exposed to  such unfriendly error messages and disgraceful page rendering ๐Ÿ˜‰

      And the best part is, except developers, no user is interested in "what happened" in this case, so why would you close their client ? I totally understand that this kind of error is not only caused by IE, but wouldn’t it be more "user-friendly" to just report the error in the console and just not continue the script execution ? I thought that would be the very basics of user interaction flow managment… seems not, at least not for Microsoft.

    9. emu says:

      <p onclick="innerHTML='<CENTER></CENTER>’"><button>click here</button></p>

      <iframe src="javascript:'<script>top.ff1={abc:function(){}}</script>’" width=0 height=0 name="f1"></iframe>

      <button onclick="f1.location=’about:blank’;setTimeout(‘alert(ff1.abc())’,0)">click here</button>

      <iframe src="javascript:'<script>top.ff2={abc:function(){}}</script>’" width=0 height=0 name="f2"></iframe>

      <button onclick="f2.location=’about:blank’;setTimeout(‘alert(ff2.toString())’,0)">click here</button>

    10. Jack says:

      Some of you act like this behaviour was the end of the world…

      ZiggyFish, have you used IE at all?

      Why doesn’t CTRL-E and CTRL-T work for you after setting Google to the default search provider?

      If things like this makes you use another browser I don’t know what to say…

    11. That’s what I call a move into a right direction. Keep the complicated things out of the common user’s interface and let the page render even if browser thinks it’s broken.

    12. DD says:

      Why is IE the only browser that has a problem with this? I have to handle this specifically for IE and I usually wait for document.readyState=="complete" before attempting to add elements to the page. This is highly inconvenient and something I don’t have to do for Firefox or Safari. I’ve seen that in some cases (but not all) that allowing the write to happen where document.readyState=="interactive" can also be acceptable.

      This is especially annoying when your code is running in an iframe and you want to "deploy" some code or DIV’s into the parent page.

      Will this change be applied to IE6 and IE7 also ? Hint: Please say yes. If you thought it was a problem worth dealing with (or at least "half" dealing with because you’re still logging it as a script error when really it isn’t, it’s a browser error) then surely IE6 and IE7 which are both still-supported browsers, deserve the fix too. I don’t like that a script error will still be logged, but it’s better than the operation aborted error.

      If the behavior I’ve observed in Firefox is to be believed, then I think what they do is store the "add" request in a pending operations queue and when the appropriate closing tag is parsed, they then execute it.

    13. PinkDuck says:

      This issue was most irritating, and most often happened on the MSDN site with either failed JavaScript includes or Operation Aborted killing the application. I ended up using Google and Firefox to search/browse the content.

    14. Tino Zijdel says:

      So if I understand correctly you have not really fixed the problem but merely made the result of this bug/shortcoming less annoying? (although throwing an error and stopping script execution is still annoying).

      You mention yourself that other browsers do tend to deal with these situations, although not all in the same way e.g. for the removeChild scenario, but afaik they do not throw errors and stop script execution…

    15. J says:

      I have never ever seen this error message and I’m a developer.

    16. Josh says:

      Trident still has problems, but I can see that it’s going to take a while to get it up to speed. Afterall, you can’t make a brand new rendering engine in just six months.

    17. Jeria says:

      Wouldn’t it better to fix the actual bug? This works fine in Safari, Opera and Firefox.

    18. Ian Hickson says:

      For what it’s worth, the HTML5 spec defines precise rules for handling all these edge cases, so once browsers implement them, these issues will all go away.

    19. Lachlan Hunt says:

      Why is there a restriction on appending new nodes to unclosed elements (other than the parent of the script)?  Wouldn’t it be better to actually fix your broken DOM implementation, instead of just covering up errors like this.

      FWIW, the HTML5 spec actually handles all of these cases sanely. Maybe you could take a look at that for a real solution.

    20. CornedBee says:

      > A simple web search for "KB927917"

      There is no such thing as a simple search for a database ID.

    21. vtondrjc says:

      I agree with George

      "This was one of those… "OMG! I can’t believe they shipped IE7 with this not fixed!" things.


      and also with DD.

      The "better" error messaging in the IE8 beta may (temporarily) help BUT this is a browser bug that should be FIXED, also in IE6 and IE7.

      By the way, I pointed this problem, as well as the root cause (unclosed div), out in response to a previous blog as well as in the IE newsgroup but got no response – neither from Microsoft nor from an MVP.

    22. Ed says:

      The way this reads is that IE8 is being fixed with duct tape and bubble gum.  Why don’t you guys FIX the bug, at least in the appendChild() case.  Stopping parsing and script execution is just dumb, especially since your competitors have been dealing with this in some fashion for ages.  

      It really is time for Microsoft to decide to ship a quality browser instead of a collection of patches.  I hope IE8’s release is driven by compliance and quality criteria rather than an arbitrary deadline.  As a developer, I already spend over half my time trying to find workarounds to IE bugs like this one.  I don’t want that to increase with IE8.

      It also really amazes me how many pats on the back the IE8 team gets for doing the basic things, like following standards and fixing bugs.  I’ll pat them on the back when they do those things and produce a faster, more innovative browser than the competition.  Catching a parsing exception and logging it instead of showing a modal dialog is NOT praiseworthy.  It just means that someone at Microsoft woke up for a couple of hours.

    23. anonymous says:

      I remember getting this on bloated large media comporation sites and on Neowin.net. Most of the times after clicking OK, I quickly pressed Esc so IE didn’t navigate to the error page and whatever part was loaded was still readable. Thank you for making it go away. IE8 is turning up to be much better than IE7 and a must-have upgrade but still the IE team has a very long way to go before claiming standards compliance (cough) XHTML, XML (and various standards like XForms, MathML, XPath 2.0 etc), DOM 2, DOM3, CSS3, SVG, ECMAScript extensions 1.5/1.6/1.7/1.8 and future technologies, HTML 5 and ECMAScript 4.

    24. mocax says:

      I’ve not encountered this before. Happens to dubious websites with lots of ads?

    25. jun says:

      "This issue was most irritating, and most often happened on the MSDN site…"

      Microsoft itself uses the absolute worst javascript practices, and its fanboys come in second.  To help our your peeps, MS, you need to to queue the add or remove request and execute it when the tag is closed rather than just allow YOUR OWN CODE and that of your biggest fanboy customers to crap out.

    26. Tino Zijdel says:

      I took the liberty to translate this article into  more comprehensible language: http://crisp.tweakblogs.net/blog/678/ie8-operation-(now-silently)-aborted.html

      Ian/Lachlan: I’d appreciate if you could pinpoint me to the right sections in the HTML5 WD that actually deals with this; I couldn’t find a section specific to DOM operations within inline script.

    27. L says:

      This happens very often with the new version of GMail. Also some airline sites have this problem. It’s a big AJAX pain. Glad to see the behaviour will improve.

    28. anonymous says:

      Btw, this page (http://arstechnica.com/journals/microsoft.ars/2008/04/22/microsoft-releases-two-more-ultimate-extras) is excellent for perfecting IE8’s image scaling algorithm.

    29. Ian Hickson says:

      Tino: There is no one place to point to really, it’s just fundamental to the way the parser algorithm is written. Basically the DOM tree is almost never examined by the parser, instead the parser keeps and uses a separate set of state that is unaffected by changes to the DOM. For example, appends almost always happen to elements in the "stack of open elements" rather than to elements in the DOM. (Off-hand the only exception I can think of is for the handling of misnested formatting tags, which have a complicated algorithm that does dive into the DOM, but again the way the algorithm is designed it should work regardless of what a script has done to the DOM.)


    30. Tino Zijdel says:

      Ian: yes, that helps and confirms what I already thought would be the case. It is a bit confusing though that the spec covers document.write() and .innerHTML in detail but fails to mention normal DOM manipulation in the same section…

    31. I presume most if not all browsers execute onload after the page has finished loading (or at least the (X)HTML content). In this example we’re then dealing with inline JavaScript which is a mark of an amateur. JavaScript should only be called via script element within the head element of a page. So while it’s nice to have this bug fixed it champions non-standard code. Frankly I’d prefer it if a post was made explaining to webmasters to remove all their inline JavaScript and make proper use of the onload event. Though it’s understandable that this behavior was adjusted on account of the visitor and not the webmaster.

    32. Chris Quirke says:

      I read a lot of "why don’t you just fix this" here, but I’m worried about creating possible exploit scenarios if IE glosses over this and carries on truckin’.  

      All the ingredients may be there; scripting, references to deleted objects, delivery via arbitrary off-site content such as ads, etc.

      Let’s be careful out there, and NOT give the content the "benefit of the doubt" – while still preserving whatever’s loaded so far (unless that in itself constitutes a potential exploit scenario).

      Does this tie into the scroll wheel jerk-back-to-top bug that kicks in when you wheel down a page that’s still loading, without transferring UI focus to the scroll bar?  That’s a new bug in IE8b1 (as tested in Standards Mode) and very irritating.

    33. Tino Zijdel says:

      John A. Bilicki III: I absolutely fail to see why using inline script is a "mark of an amateur". In most cases you really want to attach your (unobtrusive!) JS behaviour as early as possible which is normally right after the parsing of the section you want to apply it to. Waiting for DOMContentLoaded (or worse – window.onload) will result in a notable ‘flash of other behaviour’ or even a flash of style-change when the styling gets adjusted on behalve of the added behaviour (such as a drop-down menu).

    34. Chris Quirke says:

      Heh… it’s baaack, and hits on this page…


      …even if active content is refused.  Back navigation from the can’t-load page gets the wanted page back, which is good.

      Tested with IE8b1 over IE7 RTM on XP SP2, Standards Mode, set to prompt on active content.  In this particular test, all such prompts were cancelled (i.e. active content was refused), which suggests a different mechanism?

      I’ll try for repro, and log as a "bad page" if I succeed.

    35. Mitch 74 says:

      @ JAB III: no, it’s not only in inline Javascript that this happens: it also happens with advanced event models scripts hosted in the HEAD section.

      The reason why: the only event you can detect with IE is body.onload, which is fired only when the page is done loading all its images, CSS, iframes etc.

      Because of this, you may get heavy flashing or even 30-seconds delayed Jscript execution if you rely on body.onload, which is a big no-no.

      Other browsers allow you to execute your code sooner, on document.DOMContentLoaded (Firefox, Safari, Opera, Konqueror…), which, as its name implies, fires as soon as the DOM is complete and the browser is now loading images and stuff: firing your script on this event ensures that Javascript runs on a complete DOM, meaning that you can edit it at will, but it is not delayed by some missing resource or injected code, making the page not jerky – or much less so.

      Since DOMContentLoaded doesn’t exist under IE, you need to use another solution:

      – put your inline script at the very end of the body: usually works, but if you get some ad in your page that starts executing its code and adds some more stuff to the page bottom, this solution will, instead, trigger the error mentioned here

      – put your code inline where you actually need it: it is less sensitive to the above problem, because it will crash regardless of other modifications made by injected code.

      – use a quirky way to implement something equivalent to DOMContentLoaded under IE: in your document’s HEAD, you execute a little bit of Jscript, but you add the DEFER property to it – so that it fires when the page’s HTML is done loading (pretty much when DOMContentLoaded would fire.

      Say, all your Javascript is executed through a single function initCommon():


      document.write("<script id=’__ie_onload’ defer=’defer’ src=’://’></script>");

      script = document.getElementById("__ie_onload").attachEvent(

      "onreadystatechange",function() {

      if (event.srcElement.readyState === "complete") {initCommon();}});}

      Other browsers do the same with




      And for the odd browser out there, you add:


      Be careful though, make sure that only one of them gets run, because otherwise IE or recent other browsers will run the function twice (one on DOM ready, one on page load).

    36. Max says:

      I really appreciate the fixes for standards in IE8B1 so far, but I’m curious what the stance is on the following.

      If you want to set (from script) the "for" attribute for a [label] element so that it would be linked to a field, you needed to call:


      of course, IE6, IE7 choked on this, and thus you had to call:

      //IE bug workaround


      I’ve noticed in IE8B1, on a page rendering in IE8 Standards Mode, that if you call:


      it works! (great!)

      but if you call the old hack:


      it won’t work at all.

      I’m totally fine with this move to standards, but I’m curious to know "which" methods will still work both ways, and "which" will only work the correct way.

      e.g. will IE8 still support these line(s) or will these fail too?





      Thanks, Max

    37. Frankie says:

      Is it just me or does this post title seem a bit odd?

      "What Happened to Operation Aborted?" sounds as if you felt this was a *feature*, that is being removed in IE8.

      It has been very frustrating that this has existed in IE7 for so long without a fix.

      Is this fix going to be back-ported to IE7?  I don’t see many enterprises upgrading to IE8 right away without IT dept approval (could be 2010)

    38. Ronan says:

      You all have little to whine about.

    39. rick says:

      How about an end-to/redesign of those pesky dialogue boxes (including vista ones) all together e.g. http://blog.mozilla.com/faaborg/2007/03/06/would-you-like-to-redesign-notification-in-firefox-yes.-not-now.-never./

    40. Derek Kent says:

      Contrary to the blog post, you actually can pretty consistently cause this error to occur even if an element has already been correctly closed.  The difference is it doesn’t occur 100% (more like 75%).

      I ran into this problem when I had a <div> element that I would then close and follow with a script using SWFObject to add a flash movie (so as to remain XHTML 1.1 compliant).

      My web page is currently loading the flash movie after the dom is ready, although it would be trivial for me to switch back if anyone would like a working demo.

      I found the page would cause this error for IE (both 6 & 7) when loading the page for the first time about 95% of the time, and on reloading the page about 75%.  Safari, Firefox, and Opera all had no issue handling the page properly every time.

      On that note, it’s nice to hear the error message is less annoying, although I’d like to see the issue resolved as well.

    41. DD says:

      Travis (author of this article) … are you going to respond to the comments ?

    42. DD says:

      The general consensus seems to be that you should not be generating a script error, but instead should queue the request until the appropriate tag is closed. It works for the other browsers. Is this such a problem for IE to do also? Plus, don’t just fix it in IE8. We want it retro-fitted to IE6/7 also.

    43. Know what would be *really* great? If Microsoft, *nix vendors, and Apple got together and made it so I wouldn’t have to patch my site’s FONT-SIZE!

      Seriously load my site in XP, then bring it up in Ubuntu….then go over to a Mac. You’ll see it looks fine in XP because that is what I work with by default and it’s how I prefer things to look any way.

      I’m not a fonts expert but the inconsistency is beyond stupid. Please … someone get people talking about this issue; it’s beyond sad right now that I can expect my CSS dimensions to work cross platform while havnig to seriously consider serving a second style sheet *JUST* to fix font-sizes for entire platforms!

    44. Mitch 74 says:

      @JAB 3: oooh, font rendering…

      – fact 1: installed fonts are not the same from one OS to the other, so you can’t have the same rendering on all platforms; you can however select fonts with similar metrics and face (Helvetica, Arial and DejaVu, or Liberation Sans, for example, are very close)

      – fact 2: IE can’t deal with font metrics, and interpretes font size in a non-standard way

      – fact 3: glyph rendering priorities change from one platform to the other: MS tries to match to pixel grid, Apple matches to best paper representation, Linux… depends on user settings (:P)

      Solution: wait for CSS3 support and @font-face.

    45. Geld Lenen says:


      Authors almost never respond to comments made on this blog.

    46. Is it really gone in the version that everybody can download, or in a newer build? Also, does this also apply when IE is running in IE 7 compatiblity mode?

      Why I ask? This is why: http://i30.tinypic.com/35i1unq.jpg

    47. Rowan says:

      When will Beta 2 be available? Beta 1’s been out for a while now.

    48. Lead by Example says:

      This post takes about a day and a half to load.

      Please lead by example:

      1.) Crop your screenshots so that only the important parts are shown

      2.) Use PNG Crush to shrink your PNG images

      3.) Use GZip or similar for your files

      4.) Add a proper expires header to your static content (the screenshots, CSS, JS) so that every visit to this blogs homepage, doesn’t require me to download 300k of images that I already have in my cache.

    49. Tony says:

      What is really sad is that the screenshots were taken as JPEGs (look at the lossy pixelation), then converted to PNGs because that is a better format for screenshots.

      What was missed is that PNGs are better, but if you convert from a lossy JPEG its too late! You’ve already messed up the image.

      I just tried a CRUSH on the first PNG… saved 42k in image size!

      I thought it was just this site that was slow, but I think the caching thing is what is messing it up.

    50. Lubos Motl says:

      Oh, very cool, Microsoft friends read my http://motls.blogspot.com/ where this error frequently occurs and people frequently complain to me.

      Could someone please figure out what is the reason and maybe even how the scripts should be modified to avoid the problem? A nice person can submit any comment under any article in my blog.

      Also, I wonder that Firefox seems to solve it OK without creating a new scientific discipline about it. ๐Ÿ˜‰

    51. DD says:

      @Lenen – that is disappointing.

      I wonder why they offer a comments section if they don’t plan to have a dialog on the subject. So basically it’s a case of:

      "This is what we’re doing, you might all be developers with an equally valid point of view as us at MS, so have fun writing your comments, but this is what we’re doing so get used to it."

    52. Dave says:

      Haha, you haven’t figured it out yet? Large corporations generally run blogs for marketing reasons, not to increase geniune communication with their customers.

    53. Dmitri Farkov says:

      Wrong post to put this question under, but:

      I haven’t had a chance yet to check out IE8, but I just wanted to ask, are you guys going to allow prototyping in JavaScript in this version, much like Mozilla and Opera allowed?

    54. Mark says:

      @Dmitri: The entire Javascript language is based around prototypes, thus IE has supported prototypes in JS for a very very long time.  What precisely are you trying to do that isn’t working in IE?

    55. Harold says:

      @Mark (re: @Dimitri Farkov)

      Mark, JavaScript has supported prototypes since day 1 – yes.  However JScript does not fully support prototypes on many things.

      In IE, in particular:

      Object: Array  (you can’t create a true "subclass" of an array)

      Object: XMLHttpRequest (ditto, and it doesn’t support expando’s)

      Object: HTMLElement, Element, HTMLFormElement, HTMLSelectElement, HTMLInputElement etc. (all can not be prototyped on)

      As for a simple test case?… sure thing.

      I want to create a new type of Array, that supports a forEach() method.

      It can’t be done. Unless you resort to overwriting the native Array object in IE, or "steal" a copy from an "imported" iframe (which is then discarded).

      This has been talked/blogged about all over the Internet for years, and is nothing new Mark.  IE doesn’t support prototyping on many objects, and this sucks because if it did – we could fix many of IE’s bugs in our own code, thus not have to wait 12 years for a version of IE that natively supports JavaScript out of the box.

    56. Mark says:

      @Harold– Didn’t Mozilla pull out array prototyping because it allows data theft from JSON?


    57. Steve says:

      Oh, and if you’d like to vote for Prototyping to be fixed in IE8, here’s the link to the IE8 Bug Tracker for bug #333956


    58. Andrew Powell says:

      So instead of handling it, your move is to throw a js error now?


      Every other major browser out there will handle adding elements BEFORE THE DOM IS PARSED just fine and dandy. Perhaps you didn’t word your post very well. At one point it seems as though you agree that the browser should be able to handle adding new elements before the parsing is complete. Then, it seems, you pull an about face and suggest that we continue to use the asinine defer attribute (WHICH IS NON-EFFING-STANDARD).

      I’m sick and tired of these bloody hacks for IE. I had sincerely hoped that the next version of the browser would handle inline DOM manipulation WITHOUT ISSUE.  


      But alas, even though several other big boys have been doing it for years, you’re still content to let IE wallow in the same old shortcomings. The lack of a modal dialog to alert the user of this error is better, but not nearly enough to appease the masses of developers out there who are sick and tired of this sort of thing. Equate this to putting perfume on a pig. Dress it up, spray some on. In the end, it’s still a pig.

    59. Steve Roussey says:

      Please deal with the fact that it is now a defacto standard for it not to be an error. I’ll quote DD:

      "The general consensus seems to be that you should not be generating a script error, but instead should queue the request until the appropriate tag is closed. It works for the other browsers. Is this such a problem for IE to do also? Plus, don’t just fix it in IE8. We want it retro-fitted to IE6/7 also."

      Except that I would say to kill off IE6 forcibly.

    60. Derek Kent says:

      @Dave: Actually, the WebKit blog is very good about communicating with developers who post there (http://webkit.org/blog) and also has much more interesting posts.

      Take a look if you want to see the right way to manage a developer blog (you’ll also get a nice window into the future of the web).

    61. Rex says:

      @Andrew OMG! I just read your comment.  I must have misread the original post.

      I thought they fixed this! but they haven’t! all they’ve done is not show the modal dialog, and not wipe the current page content off the screen!

      "When the HTML parser THROWS THE OPERATION ABORTED EXCEPTION, rather than announce this error to the world, Internet Explorer 8 Beta 1 discreetly tucks this information away into the list of script errors associated with the webpage AND STOPS PARSING HTML AND RUNNING SCRIPT AT THAT POINT."

      (emphasis mine)

      So basically what it means is that they’ve fixed the "user experience" so that no interaction is required to deal with the BUG that IS STILL THERE!

      I’m shellshocked!  Please tell me that this will be fixed properly by the Beta 2 release!

    62. Bill says:

      @REX: Use the DEFER attribute on your script.  Beyond avoiding this browser limitation (on ie8 AND older versions) it will improve the performance of your page.

    63. Rex says:


      Thats not the point.  I shouldn’t have to use a proprietary non-standard attribute to solve an IE bug.

      More importantly, if I have another script elsewhere on the page, that LEGITIMATELY tries to interact with the elements I created/altered, BEFORE the DEFER’d script is executed, then I’m STILL going to have ERRORS.

      Please fix this bug, properly.

    64. Rex: http://www.w3.org/TR/html401/interact/scripts.html#h-18.2.1 You might as well look before speaking up. From what I see the defer attribute seems to be defined in the HTML Spec. Whatever you call proprietary, I don’t think this is.

      As for UX and bug fixing: Right, the bug remains. You may assume that different people work on the UX and the parser, so jumping into the UX people’s face for a bug they can’t and won’t fix is futile. And please remember that there are many more users than web designers/developers who will actually benefit from a better user experience. Most pages that throw this errors probably render fine and just lack ads … who cares, really?

      And you may have noticed that there are two distinct ways of dealing with that problem, outlined in the post. Both yield different results in the final DOM tree and (a) no spec is given what method to use, (b) the other user agents seem to have a hard time doing all the same. Granted, IE introduces a third behaviour here, but in any event triggering this case will yield headaches for web developers as the final DOM tree will be different from browser to browser โ€“ and this is not exactly an IE problem. You lose nothing from moving the script evaluation after parsing and before rendering and will gain consistent behaviour. From what I see, you call for a solution to a non-problem.

      (Hint: CSS bugs are harder to work around so I’d rather see those fixed than this :))

    65. Total Cluster Fudge says:

      3 words for this "fix".

      T-O-T-A-L   C-L-U-S-T-E-R   F-U-D-G-E

      Just fix the bug, don’t give us these IE-Only workaround band-aid On-Error-Resume-Next kind of amateur software development cruft.

      T-O-T-A-L   C-L-U-S-T-E-R   F-U-D-G-E

    66. Greg says:


      "UA may defer execution of script"


      As in, the browser (User Agent) can decide if it wants to or not.  As in, it isn’t important when this runs.

      But we’ve established that this is INDEED important WHEN this runs, or we wouldn’t stick the script in the middle of the DOM.

      IIRC, the defer attribute was one that MS introduced many years ago (as proprietary), that the W3C saw fit to incorporate into HTML 4.x. – though I could be wrong.

    67. Alexey says:

      Wow! A long time IE ssays me,that "Operaion Aborted" and closing. But now,its ok!

      <a href="http://colorworld.org">Thanks!</a>

    68. uncle b. says:

      <i>What caused the operation aborted error?</i>

      your crappy code, maybe?

    69. André R. says:

      Hi, know this is off topic, but I’m missing the transcript from the April chat..

      In the March transcript you wanted use cases for adding support for CSS 3 stuff:

      Please add :nth-child(), this doesn’t just affect CSS but also JavaScript since you have decided to add querySelector[All] support. Every major JS Library out there support some kind of getElementByCSS (aka $$ ) to get elements, and they  have some kind of :nth-child() support (though some of them call it :child(), :odd and :even).

      Adding :nth-child would help them (and me) accelerating those functions by using querySelectorAll if supported in most common cases (yes, :child, :odd and :even are commonly used by users of todays JS libraries / framworks).

      Also, by the time ie8 is out all other major browsers will support querySelectorAll and :nth-child (Safari already does).

      Other then that: Please force every ie < 8 user to update to ie8 when it is stable ๐Ÿ˜‰

    70. Greg Bellingham says:

      I feel it is worth correcting all the people who – in their zealous, anti-Microsoft fervour – incorrectly labelled this a browser bug. It is not a browser bug. Although I agree that the recovery scenario is a little harsh, the specific cause falls at the feet of the web developer, not the browser. If you attempt to insert tags before the page has finished loading and cause a race condition, it is your fault, not the browser’s. There is a right way to do this (waiting for DocumentComplete) and a wrong way. You cannot write bad code and then demand a perfect result. Ignoring the shortcomings of your own page design, then blaming someone else in the hope they will clean up after you is the height of arrogance. Just because other browsers turn a blind eye to your below-par code does not make it Microsoft’s fault!

    71. Andrew Powell says:

      OUR below-par code eh?

      That’s a hell of an interesting twist. Seriously, you really ought to go into politics. Shortcomings and limitations out of spec within the javascript vm, within Internet Explorer are clearly the fault of website developers across the globe. (And if you cant tell, that’s some mad sarcasm)


    72. Greg Bellingham says:

      Please don’t be juvenile about this, Andrew. Sarcasm is the lowest form of wit and it’s off topic anyway. I do tend to agree that there are annoying discrepancies between the IE VM and the JS standards. I also agree completely that it is not acceptable to have to alter content based upon the requesting browser. However that’s not what I’m talking about here. I am really fired up about that fact that some folks on this forum seem to want a situation where they do not have to prepare adequately for exceptions and then get to blame the vendor for their own lack of diligence at design time. What’s next – blaming Microsoft because your divide by zero causes a crash? Perhaps you’d like them to remove *that* dialog too?

    73. frank p says:

      well done Greg. finally some common sense. you’ll never change their blinkered zealotry tho

    74. Greg Bellingham says:

      Cheers Frank. I think ‘blinkered zealotry’ is a bit harsh, though. These guys are just looking for a solution and it *is* frustrating for all of us when the platform causes issues. But I guess I just want an acknowledgement in this *particular* case that the answer to the problem is ‘anticipate and handle a concurrency error in my scripts’ rather than ‘ask Microsoft to ignore my concurrency error’. Inserting nodes into an unparsed or partially incomplete DOM is, after all, playing off the board and tempts problems. In that case, it would be foolish not to try and design the script better, rather than pointing fingers in all the wrong places.

    75. [ASP.NET AJAX] Accesso sicuro al DOM

    76. Here’s another tricky JavaScript error that could leave you bewildered and frustrated… Internet Explorer

    77. Teamzille.de says:

      Georg Binder beschwerte sich im Vistablog vor kurzem ๏ฟฝber eine Eigenart des Internet Explorers, die wohl jedem seiner Benutzer schonmal unangenehm aufgefallen ist: Trifft der Browser beim Parsen des Javascript-Codes einer Webseite auf einen Fehler, bric