Preventing Operation Aborted Scenarios

This post follows up on my original Operation Aborted post to provide some additional information and assistance for web site owners or 3rd party script libraries.

operation aborted dialog box


Nearly a year-and-a-half ago, I blogged about an error that can occur on some websites that generate content via script. This content can cause Internet Explorer’s HTML parser to get into an unrecoverable state, which makes it doubly-hard to find and diagnose why this error is happening. When this state occurs, the HTML parser cannot continue, and simply throws up its hands and admits: “Operation aborted!”

Early in IE8’s development, we put in a mitigation that alleviated the worst side-effects of this problem. Rather than show a modal dialog and then navigate away from the page after you press OK, instead we removed the dialog and transferred the error notification into the status bar (to the script error notification area). As a result, you are not interrupted by a dialog and you can continue to view the current web page. You may not have even noticed that this error occurred; yet the HTML parser does come to a grinding halt (for that tab only) and any additional content will never be processed.

Not too long after IE8 was released, we began hearing reports of IE8 customers continuing to see the old operation aborted dialog! While we knew that we hadn’t fixed every possible scenario that could cause the dialog to appear (it’s triggered as a catch-all for many subsystems such as the navigation stack and networking), we believed that we had mitigated the worst-cases. With recent reports of users seeing the Operation Aborted dialog in IE8 we investigated further to find any additional scenarios that could be triggering the dialog to appear (rather than the script error mitigation).

In the following two scenarios, the root cause of the Operation Aborted issue is the same (for details, please read my previous post), but the way in which it happens in these scenarios causes IE to bypass the mitigation that we put in place for IE8.

Scenario 1: Nested Parsing after Operation Aborted

<script type="text/javascript">

In the HTML above, the effect of the first line of the script is to trigger the Operation Aborted problem. In IE8 this is mitigated as previously mentioned. However, if sometime later a document.write API call is issued as shown in the second line of script, all versions of Internet Explorer, including 8, will present you with the old operation aborted dialog.

Scenario 2: Operation Aborted in error handlers

<script type="text/javascript">
window.onerror = function() {
var el = document.getElementById("div2");
<div id="div1"></div>
<div id="div2" onclick="alert('hi';"></div>

In this HTML file, a script error (in the onclick event handler) has a run-time error, which causes the window object's onerror handler to be invoked. In this scenario, if Operation Aborted is triggered in the error handler, the dialog will also show in IE8.

Programmatically Detecting Operation Aborted

When this error dialog occurs, it is very hard for web developers to find the problem and fix it. Often (and in most cases we’ve seen) the problem is introduced in third-party scripts that are referenced by the affected page. To help web developers quickly find and fix the problem, we’ve written a little script that should help.

This script must be run as the first script in the page that is experiencing the Operation Aborted error. It overrides the usage of innerHTML and appendChild by first checking the parsing frontier before allowing the action. AppendChild is by far the most common DOM entry point that can trigger Operation Aborted, followed by innerHTML. The script may flag false positives, but we wanted to err on the side of being overly cautious.

This script relies on a feature enabled in IE8 standards mode only—Mutable DOM Prototypes. Thus, it will only work for pages that use IE's most standards-compliant mode. See this post on compatibility view for more details on the mode that IE is interpreting your page in. However, the operation aborted problems that this script identifies (in IE8 standards mode) also apply to IE7 and IE6 thereby helping you diagnose and fix this issue in any version of IE.

To use the following script follow these steps:

  1. Add a script element to the head of the page in question. This script element should be before any other script element on the page.

  2. Place the following script text within that script element (or reference a file containing it from the src attribute)

  3. Set the "f1" and "f2" feature values

    1. Setting "f1" to true will skip DOM calls that could potentially cause the Operation Aborted error. However, this will also result in a change in program flow, and other script errors could result.

    2. Setting "f2" to true stops program flow at the point of a potential Operation Aborted error and breaks into the debugger (external or built-in JavaScript debugger). This is where you can analyze each occurrence to see what assumptions were being made and how the program flow can be altered to prevent the problem.

  4. In IE, navigate to the page in question.

  5. Start the JavaScript debugger by pressing "F12" and then selecting the "Script" tab in the Developer Tools, and press the button "Start Debugging".
(function() {
// Feature switches
// WARNING: 'true' may cause alternate program flow.
if (!window.console) {
window.console = {};
window.console.warn = function() { };
var frontierCheck = function(host) {
// Is host on the frontier?
while (host && (host != document.documentElement)) {
if (host.parentNode && (host.parentNode.lastChild != host))
// This is not on the frontier
return true;
host = host.parentNode;
if (!host || (host != document.documentElement))
return true; // This node is not on the primary tree
// This check is overly cautious, as appends to
// the parent of the running script element are
// OK, but the asynchronous case means that the
// append could be happening anywhere and intrinsice
// knowledge of the hosting application is required
console.warn("Potential case of operation aborted");
if (f2)
// Step up two levels in the call stack
// to see the problem source!!
if (f1)
return false;
return true;
var nativeAC = Element.prototype.appendChild;
Element.prototype.appendChild = function() {
// call looks like this:
// object.appendChild(object)
// Go back one more level in the call stack!!
if (frontierCheck(this))
return nativeAC.apply(this, arguments);
var nativeIH = Object.getOwnPropertyDescriptor(Element.prototype, "innerHTML").set;
Object.defineProperty(Element.prototype, "innerHTML", { set: function() {
if (frontierCheck(this))
nativeIH.apply(this, arguments);

We recognize that the operation aborted dialog and its mitigated cousin in IE8 are still the source of significant web developer pain. We hope this information and prevention script help you to diagnose and fix issues related to Operation Aborted in IE8 (and older versions of IE).

-Travis Leithead
Program Manager

Comments (38)
  1. Anonymous says:


    You’re obviously an IE fan boy. still crashes IE

    Browser Chokes when fed Junk

    document.write()ing "document.close()" into iframe freezes browser

    CPU hangs (infinite loop) when examining read-only properties in Developer tools

    All these 4 bug reports (clean, reproducible) were filed before (even months before) final release of IE 8.

    All these bug reports involve serious (criticality, severity, gravity according to objective criteria) issues.

    All these bug reports were closed with a "We will consider this in a future version of IE." or a "hope to address it in a future version of IE" comments. The next IE version is possibly in the 2010 Q2-Q3 range.

    James Hopkins now reports over 20 regressions regarding IE 8, including a tab crash. Zoffix Znet and Hilbrand Edskes have found several regressions in IE 8 as well. Overall, there’s probably known, reproducible, testcase-ed 50 regressions in IE 8.

    At this point, I sincerly think there ought to be a IE 8.1 or IE 8.5 release to fix those crashes, hang, regressions.

    Right now, there are at least 5 known crash bugs in IE 8, all reproducible, all public, well documented with testcase and at least 2 serious hang application bugs.

    Other browsers have bugs, even security bugs, even occasionally crash bugs. But the main difference is that they have been tackling bugs, including security ones, a lot more consistently in the last 10 years. They also release minor releases more frequently. Other browsers have had fewer advisories from, with (overall, in average) less criticality and shorter time of releasing fixes. See David Hammond’s graphical chart on this.

    There are people (e.g., Koranteng Ofosu-Amaah) who have said publicly that they reported serious IE bugs about insertBefore, appendChild and document.write since 1999.

    "(…) doesn’t really solve the problem of ‘How do you report a serious bug or issue to the IE team?’ and ‘If you do report an issue, how do you know if it will ever be addressed?’ These are real issues to people."

    Al Billings, ex-Microsoft project manager (9 years) for the Internet Explorer team, February 23rd 2008, IE Blog

    Gérard Talbot

  2. Anonymous says:


    I already was there and couldn’t find any significant information on IE on WM6.5 or Zune on the windows mobile blog.

    I thought it was the IE team that build those browsers for the mobile platforms and we should be here for info on things like browsersidentifation strings and such…

  3. Anonymous says:

    IE just plain sucks. Why disable the other entries comments?

  4. tester says:

    When I was testing Scenario 1, after the dialog pop up and the page "Internet Explorer cannot display the webpage" displayed, in the page I press Refresh, IE will keep show "Connecting…" in the tab, if I try to close it, a dailog box "This window is busy……..". It is normal?

    (the page was stored in local harddrive(R:test.htm) and launched directly from double click)

  5. billybob says:

    Do you think that we will ever see an IE with proper error messages?

    If you knew how much time, effort and money we put into these errors then you would have given ‘good developer errors’ higher priority then web accelerators and absolute 100% support of all the CSS2 properties that nobody has ever heard of.

    As far as errors goes, the ‘operation aborted’ one is fairly easy to work around.  As tester says, the arbitrary ‘Internet Explorer cannot display this page’ is much more painful and expensive to us, not to mention ‘Object does not support this property or method: line 0’.

  6. Richard Ayotte says:

    How’s IE 9 coming along? Will you still be using Trident or are you designing a new more robust layout engine? Trident really seams to be dated and inadequate for modern web sites. Is the strategy to avoid building a robust layout engine by pushing Silverlight?

  7. Hank says:

    @billybob: I’d much rather have a 100% support of standards than pretty error messages.

    @Richard: Starting from scratch and making up new codenames is not how real engineers work. Real engineers refactor and improve their code.

    We’ve seen dramatic improvements in Trident between v7 and v8, and there’s every reason to believe they’ll keep Trident in v9 and just continue to improve it. Maybe MS marketing *should* also slap a new code name on it just to placate the sheep who don’t know any better.

    As for the idea that layout engine "robustness" is somehow related to silverlight– you clearly don’t understand that business model at all.

  8. Richard Ayotte says:

    @Hank: <q>Starting from scratch and making up new codenames is not how real engineers work. Real engineers refactor and improve their code."</q> That really seems to be working well for MS. With that strategy, the richest software company in the world can’t compete with a non-profit organization.

    <q>As for the idea that layout engine "robustness" is somehow related to silverlight– you clearly don’t understand that business model at all.</q>. Ok wise guy, what is the business model?

  9. ted says:

    Prevent the Operation Aborted Issue? easy don’t use IE!

    Actually although it is a major frustration I must admit it is much better now and is at least something that can be worked around (for the most part).

  10. Hank says:

    @Richard: Yeah, Microsoft "can’t compete." Unless you’re actually paying attention. IE has >200% of the marketshare of ALL competitors combined, including products put out by two multi-billion dollar companies.

    As for this "Mozilla is a not for profit" red herring… have you looked at the numbers? Mozilla is Google’s pawn, financed by that company to the tune of nearly $100M per year. Mozilla is actually two organizations; the not-for-profit arm and the for-profit one.

    Lastly, you’ve forgetten that Firefox was refactored out of the original Netscape sources, so your use of Firefox as an example proves my point, not yours.

    As to the silverlight question: silverlight competes with Flash, a technology which is quite profitable for Adobe. Microsoft need not hold back IE to make money for Silverlight– they only need to take share from Flash.

  11. hAl says:

    Could the team give a few posts on the mobile IE browser for Zune and Windows Mobile 6.5 ?

  12. EricLaw [MSFT] says:

    @hAl: For content about the browsers on mobile platforms, you’ll want to check out (or request at) those team’s blogs. would probably be a good place to start.

  13. Richard Ayotte says:

    @Hank: IE can’t compete. It has market share because it’s bundled with Windows. If Firefox was bundled with Windows and IE a separate download, the numbers would be quite different. Even with the bundling advantage, IE is still losing market share which says alot about the product and how well it is competing.

    You’ve got your facts wrong about the history of the Firefox layout engine. Gecko is a complete rewrite that was started in 1997. It is not refactored Netscape 1.0 code.

    Flash and Silverlight are irrelevant in a world with HTML5, ECMAScript, CSS, SVG etc. Flash and Silverlight don’t fill any void; they’re just proprietary[1] technologies designed to lock users into a closed platform. Not sure how well that’s going to work on the Internet; a place where openness is favored.

    [1] Don’t let [insert large corporation here] lead you to believe that Silverlight or Flash are open. They’re not.

  14. Travis Leithead [MSFT] says:


    Yes this is "normal" (not ideal, but expected). I believe this happens because refresh does not reload the page from scratch, it just tries to re-parse the existing cached page… since the parser is busted for this page, then the browser just spins…

    The whole experience is just sub-optimal, and we’re working on it.

  15. Hank says:

    Richard, speculate all you want. I live in the world of reality.

    As I stated, Firefox got the Gecko code from Netscape. Nowhere in your Wikipedia article does it suggest that Gecko was "a complete rewrite" as you seem to assume and assert.

    As to the fantasy that HTML5 will magically displace Flash, you’re clearly ignorant of the history of platform technologies. The existence of a "superior" platform rarely is sufficient to displace an "inferior" platform which is more broadly deployed, used by a large number of developers, and which is supported by more tools, training, etc. Flash will be with us LONG after HTML5 is finished.

  16. Richard Ayotte says:

    @Hank: IE is losing market share and that is a reality. It has been for years now… Read the article, it’s reality.

    Since you didn’t read the Wikipedia article, here’s the part that uses the word "rewrite" because you could not seem to be able to read between the lines in the paragraphs before it.

    So here it is, from the Wikipedia article:


    In October 1998, Netscape announced that its next browser would use Gecko (which was still called NGLayout at the time) rather than the old layout engine, requiring large parts of the application to be rewritten. While this decision was popular with web standards advocates, it was largely unpopular with Netscape developers, who were unhappy with the six months given for the rewrite.


    Rewrite – that is the word that you are looking for right?

    HTML, ECMAScript, CSS are superior technologies and are inherently more broadly deployed so I’m not sure what your point is.

  17. Hank says:

    Richard, Sorry, I misunderstood your purpose here.

    I **thought** you were trying to learn something, but now I understand that you’re just trying to mislead others. As such, it’s pointless for me to continue explaining why you’re wrong.

    Setting <ignore />

  18. hAl says:


    I already was there and couldn’t find any significant information on IE on WM6.5 or Zune on the windows mobile blog.

    I thought it was the IE team that build those browsers for the mobile platforms and we should be here for info on things like browsersidentifation strings and such…

  19. Peter Watt says:

    Oh I know the answer: switch to chrome!

  20. EricLaw [MSFT] says:

    @hAl: Nope, the team behind is responsible for the desktop browser only.

  21. Mitch 74 says:

    @EricLaw: as far as I know, Windows Mobile 6.5 makes use of IE6’s version of the Trident engine. Who is in charge of maintaining that code branch? Or is the Mobile team using a snapshot and never sync’ing up with upstream?

    If that is the case, then I guess all those ‘highly critical’ bugs discovered in IE 6 since the branching will remain present, and thus IE 6 Mobile should be avoided like the plague…

  22. kenny says:

    @EricLaw – the Windows Mobile blog doesn’t support commenting and of all the posts only 2 are tagged IE (one to do with widgets, the other with emulators) so the discussion points about Mobile IE are moot.

    Even if it is maintained by other development teams since this is the IE blog, this blog should at least state or link to info about the exact version of IE on Windows Mobile, what it supports, what it doesn’t support and give some indication of whether it will ever be upgraded to a modern browser engine.

    hint hint, WebKit or Gecko.

    Even RIM’s BlackBerry browser (which is already way better than Trident) is potentially getting upgraded to WebKit with RIM’s latest acquisition.

    Currently due to lousy web standards support we don’t support Mobile IE for our applications. Only BlackBerrys, iPhones, Pre, & Android.

  23. hAl says:

    Then I would like to ask you on a better source than the windows mobile blog for info on the windows mobile browser ?

    Surely the IE and mobile browser teams have things in common ?

    Could you invite one of the windows mobile team expert for some guest post mayby ?

    The releases of the Zune and Windows Mobile 6.5 being so near with a new browser a lot of webdevelopers visiting this blog could do with some extra info on that browser as well.

  24. This is a problem I often have. The only solution I could think of was to switch browsers.

  25. IE8security says:

    Hi folks,

    here is an interesting one:

    Look towards the bottom!

  26. EricLaw [MSFT] says:

    @Mitch: As I said, the team that maintains this blog is responsible for the desktop version of IE. I’m happy to pass along the request to the mobile team that they blog more about their browser.

  27. hAl says:

    I think webdevelopers and other readers of this blog would appreciate that request.

  28. Mitch 74 says:

    @EricLaw: do you mean that the Trident code is co-maintained by both the desktop and mobile teams?

    If this is the case, and the mobile team don’t ‘broadcast’ when they do their code pull, then indeed you can’t know which code revision they are currently using.

    Sorry ’bout the noise.

  29. EricLaw [MSFT] says:

    @Mitch: I have no idea what would lead you to that conclusion.

    MobileIE & DesktopIE are far from the only cases where multiple teams work in a single source base. A few years ago, Larry wrote up a short post on the topic ( I’m sure that over the last two decades or so other folks have written on the subject as well.

  30. @ Travis Leithead [MSFT]

    > error that can occur on some websites that generate content via script. This content can cause Internet Explorer’s HTML parser to get into an unrecoverable state (…)  we believed that we had mitigated the worst-cases. (…)

    AppendChild is by far the most common DOM entry point that can trigger Operation Aborted, followed by innerHTML.

    Mr Leithead,

    1- Why not fix all of the DOM bugs related to dynamic content?

    2- Why not fix all of the DOM bugs related to appendChild and innerHTML?

    3- Why not create, release, publish an "How-to/best [recommendable] coding practices" document explaining, demonstrating how to best create dynamic content, best usage of appendChild, etc. with a few interactive examples, valid markup code, properly structured code, semantic code, etc.etc.

    Why not fix all of the related problems at the source (Internet Explorer’s HTML parser), once for all and then become a leader and a pedagogic/tutorial force in the best coding/interoperability practices?

    Why do I or anyone have to be asking the above 4 questions in this blog, today or later?

    Why not improve the rendering engine and submit ways to improve the web?

    regards, Gérard

  31. Bob says:

    Gerard, that’s a genius question! Why does Microsoft software have bugs?

    They should just fix all the bugs, **then** ship the programs. I can’t believe no one thought of that before!

    You’re brilliant! They should hire you!

  32. Bob,

    Bugs are always related to compliance with specifications, agreed specifications. If a software is supposed to support and to implement a defined, determined specification, then it can have or not have bugs with regards to such specification. It all depends.

    > Why does Microsoft software have bugs?

    In 2002, IE 6 had several hundreds of bugs (spec violations, failures of all sorts) simply because of its monopolist position: 96.6% of the whole browser market share in may 2002 according to ( ) . So the will to implement (and to fix bugs or to complete the support of) CSS 2.x, HTML 4, DOM 1 & DOM 2 interfaces in 2002, 2003, 2004 was inexistent. 7 whole years later, DOM 1, DOM 2 interfaces compliance as measured by public available test suites are under 60%: that’s true for IE 6, that’s true for IE 7 and that’s true for IE 8. All other mainstream browsers achieve above 90% for DOM 1 interfaces. For DOM 2 interfaces, IE scores are furthermore weaker.

    > They should just fix all the bugs

    That’s what a lot of people were saying in Albatross! (Chris Wilson) Blog, at least regarding known, publicly reported, testcase-ed, reproducible CSS 2.1 and HTML 4 bugs, when IE 7 was released in august 2006. You can read all this by yourself.

    appendChild has been specified in 1998 in DOM 1 Core interface: Scott Isaacs [MSFT] and Chris Wilson [MSFT] were contributors of DOM 1 Core at that time (1998). So we’re definitely not talking about some rare, recent method here or some unknown feature.

    If 11 years later after public release of DOM 1 Core, you say "AppendChild is by far the most common DOM entry point that can trigger Operation Aborted", then the obvious question would be: why didn’t you address such frequently encountered problem years ago? Why are you, 11 years after, reduce to create nicer side effects (modality, status bar notification) to handle such serious problems?

    >  **then** ship the programs.

    They (Microsoft, IE team, etc) should not ship an IE version that has known, public, reported, testcase-ed, reproducible application crash bugs and severe problems like infinite reflow loop (causing %tage of application activity to be maximized, to hog, dominate CPU). I said so before.

    > I can’t believe no one thought of that before!,, and others have. They publicly use the keyword crash,  keyword blocker, keyword zt4newcrash, regression, etc. in their bug report. IE team does not.

    Gérard Talbot

  33. Bob says:

    Gerard, Thank you! Now I understand that all other browser have no bugs!!

    I will avoid Microsoft software from now on. Thank you for helping me!

    Boo Microsoft. Yay genius Gerard!

  34. steve web says:

    @Bob – sarcasm aside Gérard has many good points and has been one of the most vocal members of this community working on fixing IE bugs.

    I welcome every comment Gérard makes as he often goes into great detail about exactly what the issues are and where they first appeared with links to test cases etc.

    As he indicated the lack of good DOM method support is the main reason why IE fails to meet the grade for developers.  The Specification API states that method "X" will do "this", yet in IE it is hard to find *ANY* DOM method that doesn’t have a flaw in the implementation.

    I too have filed many bugs, ranted at the lack of standards support, lack of public bug tracking for years.

    My hope when IE7 was in development was that MS had seen the light and was going to do "the right thing" and open up public bug tracking. However that faded when not only did it not happen, but the bug tracking they had was taken offline.

    When IE8 was in beta I hoped again that the bug tracking would be public, and fixed but no luck.

    I sincerely hope there is a plan to do the right thing with the bug tracking for IE9… we’ve waited long enough.

  35. billybob says:


    You must not be a web developer that does anything interesting with Javascript.

    I have probably discovered 2-3 bugs in other browsers, but every time I try to test on IE I normally find another show stopping bug.

    Developing for IE8 today reminds me of Netscape 4.72.  Remember how a td element out of place would just render a blank page?

    These days I do not bother getting all the features for IE, if something does not work (that works in Firefox, Chrome, Safari, Konqueror and Opera), then I do not bother to fix it and instead give IE users a downgraded experience.

    The IE team need to do more to help developers, rather than relying on us to always work around everything.  That might have worked in 1999, but not today.

    ‘Object does not support this property or method: line 0’  – Would you like to spend 3 days working around this bug/limitation?  It would be nice if the IE team could actually help developers, developers, developers, developers rather than making our lives a misery.

  36. Dissapointed says:

    yeah…"mitigation" in IE context means "Premature Hacked Patch"

  37. Tino Zijdel says:

    It’s been more than a year since I blogged about IE8’s "solution" on this problem:

    I’m actually quite dissappointed that since that time all the MSIE team has come up with as a ‘solution’ is this script to just debug those situations that should not be a problem to begin with. It’s like sweeping the crumbs on the floor under the bed and saying "look mam, my room is clean!"…

Comments are closed.

Skip to main content