January 04, 2010 Posted in programming | .net

Fixing a bug in ASP.NET Ajax and the pain of leaky abstractions

There was a time when all my energies and effort went into building web applications. In the beginning the platform I was on was Microsoft ASP 2.0, but since 2002 it became all about ASP.NET Web Forms.

I still remember clearly the excitement there was around the programming model and architecture brought by Web Forms. The new code-behind style allowed to finally separating a web page’s layout from its code logic. The server controls programming model were built so that developers could build web pages pretending they were Windows Forms.

The promise of Web Forms was that web developers would never have to touch HTML and JavaScript ever again. They could simply have to add a bunch of .NET controls to a class, set a couple of properties and web pages would magically appear in the browser.

Although ASP.NET Web Forms was designed with a noble goal in mind, it turned out the Forms/Controls metaphor never completely worked for the web.

Sure, the Web Forms model boosted productivity compared to previous technologies like ASP. However it never succeeded in shielding developers from having to deal HTML, CSS and JavaScript. That essentially meant ignoring the very basic elements of the web.

This is a story of how I was painfully reminded of this reality.

ASP.NET and the Ajax Control Toolkit

At some point in time the Web became all about rich user interaction. One way to achieve this was through the power of asynchronous HTTP requests made through JavaScript, which returned XML data. This combination is commonly referred to as [Ajax][2]. When Ajax got widespread popularity, Microsoft built upon the Web Forms model to enable developers to leverage this new programming paradigm. Once more with the promise of ever having to touch a line of JavaScript.

This effort culminated in a new infrastructure made available in the .NET Framework 3.5 and a collection of Ajax-enabled server controls. AspNetAjaxLogo Once dragged into a Web Forms page, these controls would instantly deliver rich functionality by emitting the required JavaScript code to make it happen.

Contrarily to what had been done in the past, the new Ajax controls were not made part of an official version of the .NET Framework, but only the underlying framework support they need in order to work. The control themselves were released as an open-source project called the [ASP.NET Ajax Control Toolkit][4] hosted on the [Microsoft CodePlex site][5].

The illusion

After having been away from web development for almost three years, I’ve lately been involved in a project to build a web application. Of course the customer expected a modern and interactive web application, which meant we were going to be using Ajax on the frontend to some extent.

After having brought myself up to speed on the latest innovations around Ajax in ASP.NET 3.5, I was excited at the idea of be able to deliver that kind of functionality on a web page without having to handcraft (and debug) gobs of JavaScript. Or at least, so I thought.

Facing reality

I have to admit that the Ajax support in ASP.NET 3.5 held up to my high expectations quite well. Up until the Web Forms metaphor leaked again and I was roughly brought back to earth.

It turns out the ComboBox control contained in the Ajax Control Toolkit has a nasty bug that manifested itself for me when I used it inside a TabPanel control (also part of the same library).

Here is what happens: the first screenshot shows a ComboBox control inside a TabPanel that is visible when the page loads for the first time. Below is another ComboBox control this time hosted in a second TabPanel that is initially hidden.

ASP.NET Ajax ComboBox control working

The second definitely doesn’t look right. After a quick check to [the documentation available online][8] I couldn’t find anything I was doing wrong when using the controls. The only possible explanation was that there must be a bug in the JavaScript generated by the ComboBox. Let me just check. Yes, [here it is][9].

Apparently there is currently no plan from Microsoft to fix this issue anytime soon. That could mean only one thing: I had to dig in and debug the JavaScript myself. The Web Forms’ bubble had burst once again.

The “pragmatic” workaround

After having downloaded the AJAX Control Toolkit source code off CodePlex, I started to look around among the project files. I quickly indentified that the JavaScript code for the ComboBox control is all contained in a single file found in /AjaxControlToolkit/ComboBox/ComboBox.js (actually the ComboBox.debug.js file contains the original source code while its ComboBox.js counterpart contains the [minified JavaScript][10] optimized for production).

The general design of the client-side Ajax framework and controls built by Microsoft makes a lot of sense and the source code is well organized. This allowed me to quickly arrive at the root of the problem, which is:

The ComboBox control calculates its size (width and height) during initialization relatively to the size of its parent container. If the parent container is hidden when it gets measured, the returned size will be zero. That means the ComboBox has nothing to calculate its own site against and it ends up looking the way it does.

Without having to dig too much into the inner workings of the ComboBox, I came up with the simplest possible solution to the problem:

We need to make sure that the ComboBox’s parent container is visible during the control’s initialization phase. That way the ComboBox’s size can correctly be calculated and assigned. Afterwards we can restore the parent container to its original state.

In order to achieve this I added the following code (lines 9-16 and 30-40) to the ComboBox.debug.js file:

AjaxControlToolkit.ComboBox.prototype = {

    initialize: function() {

        AjaxControlToolkit.ComboBox.callBaseMethod(this, 'initialize');

        // Workaround for issue #24251
        // http://ajaxcontroltoolkit.codeplex.com/WorkItem/View.aspx?WorkItemId=24251
        var hiddenParent = this._findHiddenParent(this.get_comboTableControl());
        var hiddenParentDisplay;

        if (hiddenParent != null) {
            hiddenParentDisplay = hiddenParent.style.display;
            hiddenParent.style.visibility = "visible";
            hiddenParent.style.display = "block";
        }

        this.createDelegates();
        this.initializeTextBox();
        this.initializeButton();
        this.initializeOptionList();
        this.addHandlers();

        if (hiddenParent != null) {
            hiddenParent.style.visibility = "hidden";
            hiddenParent.style.display = hiddenParentDisplay;
        }

    },
    _findHiddenParent: function(element) {

        var parent = element.parentElement;

        if (parent == null || parent.style.visibility == "hidden") {
            return parent;
        }

        return this._findHiddenParent(parent);

    }

}

Yes I know this isn’t the most elegant solution, but it works. After all, I said it was going to be pragmatic.

Once I made sure the patch worked correctly, I used the freely available [Microsoft Ajax Minifier][13] to produce a new ultra-compact (or [minified][14]) version of the ComboBox.js file.

Integrating the workaround into the solution

The workaround itself may not be a piece of art. However the way it got integrated into the existing ASP.NET web application is quite elegant in my opinion. Let me give a quick background first.

With ASP.NET Web Forms 3.5 Microsoft introduced a new mechanism for delivering JavaScript content into web pages. This is done by a specialized server control called the [ScriptManager][15].

All controls that need some piece of JavaScript code to in order to work, have to register the required scripts with the ScriptManager. Its responsibility is to make sure that the links to the appropriate resources are ultimately included in the page output.

The ScriptManager obviously plays a central role in the ASP.NET Ajax infrastructure. However it has some great features too. In this case I’m referring to the possibility to substitute a JavaScript resource required by a server control with a local resource. [Scott Hanselman][16] wrote a [great article explaining how to take advantage of this feature][17], which served me well in this case.

Since all JavaScript files contained in the Ajax Control Toolkit are statically compiled in the AjaxControlToolkit.dll assembly, the only way to replace the original ComboBox.js file with the patched one without having to deploy a recompiled version of the library, was to substitute the original reference within the ScriptManager and have it point to a local version of the file.

Here is how it was done:

<asp:scriptmanager id="scmScriptManager" runat="server">
    <scripts>
        <asp:scriptreference path="~/UI/Scripts/ComboBox.js"
                             name="AjaxControlToolkit.ComboBox.ComboBox.js"
                             assembly="AjaxControlToolkit, Version=3.0.30512.20315,
                             Culture=neutral, PublicKeyToken=28f01b0e84b6d53e" />
    </scripts>
</asp:scriptmanager>

What about the original ComboBox.debug.js file? Well, the ScriptManager is smart enough to deliver the appropriate version of the file whenever debugging is enabled in the web application’s configuration file. This will work automatically as long as both files are located in the same folder on the server and are named according to the following convention:

Original: filename_.debug._js
Optimized: filename.js

You can download the modified JavaScript files from the link at the end of this page. Note that they are based on and will work with the [Ajax Control Toolkit release 3.0.30512][18].

Conclusions

The Ajax support built into [ASP.NET 3.5 Web Forms][19] together with the control freely available in the [Ajax Control Toolkit][20] is a powerful combination. When used wisely it will allow you to get quite far in creating rich and interactive web pages without having to worry about JavaScript.

However we all know that [software abstractions are leaky][21], and this is especially true for the one that is ASP.NET Web Forms. That means that sooner or later you will have to take control of what’s being sent down to the browser, whether it be the HTML markup, CSS stylesheets or JavaScript code. And when that time comes, you’d better be prepared.

Download Ajax Control Toolkit ComboBox JavaScript files </i> </ul> </div> /Enrico [2]: http://en.wikipedia.org/wiki/Ajax_(programming) [4]: http://ajaxcontroltoolkit.codeplex.com/ [5]: http://www.codeplex.com/ [8]: https://ajaxcontroltoolkit.codeplex.com/wikipage?title=ComboBox%20Control&referringTitle=Tutorials [9]: http://ajaxcontroltoolkit.codeplex.com/WorkItem/View.aspx?WorkItemId=25295 [10]: http://en.wikipedia.org/wiki/Minification_(programming) [13]: http://aspnet.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=35893 [14]: http://en.wikipedia.org/wiki/Minify [15]: http://msdn.microsoft.com/en-us/library/system.web.ui.scriptmanager.aspx [16]: http://www.hanselman.com [17]: http://www.hanselman.com/blog/ASPNETAjaxScriptCombiningAndMovingScriptResourceaxdsToStaticScripts.aspx [18]: http://ajaxcontroltoolkit.codeplex.com/releases/view/27326 [19]: http://www.asp.net/ [20]: http://www.codeplex.com/AjaxControlToolkit [21]: http://en.wikipedia.org/wiki/Leaky_abstraction

Enrico Campidoglio

Hi, I'm Enrico Campidoglio. I'm a freelance programmer, trainer and mentor focusing on helping teams develop software better. I write this blog because I love sharing stories about the things I know. You can read more about me here, if you like.