When Sys.Application.initialize Causes Operation Aborted in IE

As you might already know, I’m a power user of ASP.NET AJAX. I’ve been using it in large commercial projects for over three years and I’ve come to love JavaScript and be somewhat of an ASP.NET AJAX expert. In fact, I even co-authored a book on ASP.NET AJAX Server Control development with my bud Adam Calderon if that helps lend me some credence.

So being a power user of ASP.NET AJAX I’ve had to learn a few things about how it all works so I can teach others how to use it properly and spread the programming load around the office. This especially means how the Microsoft AJAX Library works (the client runtime that’s added to the page whenever you use a ScriptManager server object) and how Sys.Application, the client runtime object of sorts, initializes.

So it’s been a real problem for me that I hadn’t been able to solve a particularly detrimental problem that’s been occasionally occurring in the mapping portion of our application that I really felt shouldn’t have been possible to happen. The problem that we saw was the dreadful Internet Explorer Operation Aborted error. The Operation Aborted error, which occurs when the DOM is illegally modified and causes the page to completely fail, was occurring on slower connections when the map was loaded for the first time. It was really difficult for me to believe it had anything to do with either our code or the Microsoft AJAX Library because our mapping code was relying upon Sys.Application to ensure that we didn’t modify the DOM illegally and since I knew how the initialization routine of Sys.Application prevented illegal DOM modification, the error shouldn’t have been possible.

Obviously I was wrong and somewhere something was going wrong.

It wasn’t until a coworker of mine, John C., was assigned the task of tracking down the root of the error no matter what did he figure out that the way

Sys.Application prevented illegal DOM modification didn’t work properly in all situations.

This is a huge deal as every ASP.NET AJAX programmer relies upon Sys.Application.initialize (using Sys.Application.add_init(handler)) to create components at a safe time and not modify the DOM illegally. If it doesn’t work right in certain situations, we can no longer rely upon it at all.

So now that I’ve made this claim that Sys.Application.initialize is broken, let me explain why (BTW, John figured this out, not me).

First, let me describe what Sys.Application.initialize is supposed to do. It is supposed to initialize all components once the DOM has been fully built so that the components can modify the DOM at a safe point and not get the previously mentioned Operation Aborted error. It does this by executing functions that have been attached to the Sys.Application’s init event.

Here’s Sys.Application.initialize’s code:

function Sys$_Application$initialize() {
    if(!this._initialized && !this._initializing) {
        this._initializing = true;
        window.setTimeout(
          Function.createDelegate(this, this._doInitialize), 0);
    }
}

The bolded code is what is important here. What it does is place the _doInitialize method on a timeout that executes after 0 milliseconds. Putting a method call on a timeout of 0 means execute the function as soon as possible and is used by JavaScript programmers to setup a function to execute as soon as JavaScript has completed executing the current call stack. In this case, the _doInitialize method is supposed to execute after the DOM fully loads, but before the binary content of images, flash objects, SilverLight files, etc. have been downloaded. This means that _doInitialize will execute when it’s safe to modify the DOM because it will have been fully created, but will not suffer the same performance problem as window.onload because window.onload waits for the binary content to be loaded before executing. This is in place of the DomContentLoaded event, which IE doesn’t yet support.

This function makes the assumption that the JavaScript executor will not allow the timeout to expire and execute until the DOM has been fully loaded. Unfortunately, in IE 6 and 7 under not-so-special circumstances this isn’t the case and the _doInitialize method executes too early, and components are created that may illegally alter the DOM.

(BTW, this is most likely this is an IE bug and not an ASP.NET AJAX bug, but you program with the browser you’ve got; not the one you’d like to have.)

First, some credit.

John C. at work figured this out because I didn’t want to believe that there could be this big of a problem in ASP.NET AJAX. Nobody has to tell me what a mistake that stubbornness was. Not that I distrust Microsoft or don’t still believe that the ASP.NET AJAX guys are good programmers, but I should know better. Programming is difficult. Problems crop up everywhere.

Also, Jonathon Snook wrote this blog entry that describes exactly what the Microsoft AJAX Library does in its initialize method. His code was pulled from Stuart Colville’s blog entry on the same subject and they were both disproven by Remy Sharp on his code page, which I’m now going to repurpose inside of the ASP.NET AJAX environment to prove that the problem exists here as well.

Here’s the ASPX page that shows the problem. It creates a Component that updates the body’s innerHTML by adding a handler to Sys.Application’s init event. This should be a safe creation because it won’t execute until the page’s DOM is complete according to the way the Sys.Application.initialize method is supposed to work. It also has another JavaScript file, SlowProcessor.ashx, that it downloads using an HttpHandler I created. This script tag will take 5 seconds to download and it will cause the page to think that the DOM is fully loaded when its still processing this script tag.

Finally, I’m going to mimic the way ASP.NET AJAX places the Sys.Application.initialize method on the page in order to control its placement rather than use a ScriptManager control which automatically places it on the page in as far as we’re concerned, a random location.

<%@ Page Language="C#"
   AutoEventWireup="true"
   CodeBehind="Default.aspx.cs" 
   Inherits="SetTimeoutProblem._Default" %>

<html>
<body id="body">
    <form id="form1" runat="server">
    <!-- mimic ScriptManager to control the placement of Sys.Application.initialize -->

    <script src="/ScriptResource.axd?d=ttvrcGVUIdv_SRtdTctT62BwR7DabheV266
                  QT9bIy8qlCUtgS_np4fr7dEn7hnH1MboOfeP2xmD3rkgpGF3xDarshL
                  la_8nQ8a0zAi4FlH01&t=ffffffff8bc43548"
        type="text/javascript"></script>

    <script type="text/javascript">
    //<![CDATA[
    if (typeof(Sys) === 'undefined') 
      throw new Error('ASP.NET Ajax client-side framework failed to load.');
    //]]>
    </script>

    <script type="text/javascript">
        MyComponent = function()
        {
            var body = document.getElementById("body");
            body.innerHTML += "this body's appended updated text";
        };
        MyComponent.registerClass("MyComponent", Sys.Component);

        Sys.Application.add_init(
          function() {
            $create(MyComponent, {"id":"MyComp"}, null, null, null)
          }
        );

        Sys.Application.initialize();
    </script>

    <script src="SlowProcessor.ashx"
            type="text/javascript" 
            charset="utf-8"></script>

    </form>
</body>
</html>

And now the page’s code behind

using System.Threading;
using System.Web;

namespace SetTimeoutProblem
{
    public partial class _Default : Page
    { }

    public class SlowProcessor : IHttpHandler
    {
        #region IHttpHandler Members

        public bool IsReusable
        {
            get
            {
                return false;
            }
        }

        public void ProcessRequest(HttpContext context)
        {
            Thread.Sleep(5000);
            context.Response.StatusCode = 200;
        }

        #endregion
    }
}

So when the page loads it does two things. First, the body’s innerHTML looks like it’s updated successfully as I show in the image below.

But as the download of the script file completes, we get the Operation Aborted error.

Yikes!

As of right now we’re implementing a work-around at work that will require us to deploy our own custom version of MicrosoftAjax.js file and alter our ASPX pages that use the ScriptManager object to manually call a different initialization method on Sys.Application once the body tag has closed. This will give us the safety of knowing the DOM has fully loaded and also give us the performance of not waiting for graphics to load before executing.