ASP.NET AJAX … continued

Last week I was angry. Today I’m disappointed.

ASP.NET as a platform rocks, and being the Microsoft zealot I am, we chose to use ASP.NET AJAX behind visitscandinavia.com.au. It’s no longer in beta. It supports IE6, IE7, Firefox 1.5 and Safari 2.0. Good to go – right? Unfortunately, that hasn’t been our experience.

Luckily, the actually AJAX requirements of this project are very minimal (only two parts of the whole site), but the headaches we’ve experienced along the way are starting to outweigh the benefits. I trusted the framework, and on tight timelines it has come back to bite me in the ass. Even the bits that are supposed to work for everyone don’t seem to work for me (see “Any Browser + UpdatePanel = Nothing” below). This made me angry.

Here are some of my thoughts at the moment …

 

Safari 1.3.2 = Neglect

No support for Safari 1.3.2 at all. This was documented, so this is ok. Considering the number of alternatives on the market that do work with Safari 1.3.2, this disappoints me, but they documented it so it’s ok. For this project, Safari 1.3.2 is a very small sliver of the userbase. I think there should be at least some partial support here for things like the client side library – Sys.UI.DomElement, etc.

 

Safari 2.0 = Boom

The first problem was pretty major for us. As I documented in my previous post, the framework failed to do anything useful (like actually load) on Safari 2.0 through 2.0.3. The word I’m hearing from ASPInsiders is that the documentation is actually wrong and should read 2.0.4 not 2.0 – I’m waiting to hear the final response on this. Really, if the documentation gets fixed this could be ok, as most Mac users are up-to-date with minor builds. I found this especially painful though, as one of the first things I did when trying to debug it was start with a blank project. When even that failed, it wasn’t a great confidence boost.

 

Safari 2.0.4 + <fieldset /> + border:none; + ModalPopupExtender = Big Boom

This bug requires a pretty specific set of elements to be in place, however I’m still surprised it wasn’t picked up earlier. In most of the examples where I’ve seen a ModalPopupExtender used, it is displaying some nice little gadget like this:

Considering the gadget, like most others, contains a group of related fields the contents of the gadget should be wrapped in some semantic HTML like so:

<fieldset>
    <legend>Currency Converter<legend>
    ... form elements ...
</fieldset>

Now, the rendered appearance of a fieldset is really rather ugly and also inconsistent between browsers. Lets fix that with some CSS:

 fieldset { border: none; }

Trigger the updated panel and big boom – Safari itself just crashed after ending up in an infinite loop of updateScrollInfoAfterLayout() calls in the com.apple.AppKit library. This is 100% replicable for me on Safari 2.0.4.

The workaround is currently to use this rather ugly CSS instead:

fieldset { border: solid 1px transparent; margin: -1px; } /* Needs to be a transparent border to avoid crashing Safari 2.0.4 — border:none in conjunction with ajaxToolkit:ModalPopupExtender blows up the browser. */
* html fieldset { border: none; }

This could be a Safari problem, it could be a bug in the extender that Safari isn’t handling very well. Either way, it’s pretty broken.

 

Any Browser + UpdatePanel = Nothing

This one’s the cracker.

To me, this is pretty basic code:

<asp:UpdatePanel runat=”server” ID=”UpdatePanel”>
    <ContentTemplate>
        <asp:Label ID=”Proof” runat=”server” />
        <asp:Button ID=”Trigger” runat=”server” OnClick=”Trigger_Click” />
    </ContentTemplate>
    <Triggers>
        <asp:AsyncPostBackTrigger ControlID=”Trigger” EventName=”Click” />
    </Triggers>
</asp:UpdatePanel>

Apparently it’s there’s something wrong with my particularly little setup, because it’s rendering out broken JS that the browsers are refusing to even parse:

<input type="submit" name="ctl00$ContentPlaceHolder$Trigger" value="" onclick="javascript:WebForm_DoPostBackWithOptions(new WebForm_PostBackOptions(&quot;ctl00$ContentPlaceHolder$Trigger&quot;, &quot;&quot;, true, &quot;&quot;, &quot;&quot;, false, false))" id="ctl00_ContentPlaceHolder_Trigger" />

Notice the escaped “&quot;” within the onclick parameter?

None of my client-side code can be the culprit as the rendered output is just plain wrong.

I’ve got working instances of the UpdatePanel in plenty of other places (even some already within this same application), so there’s just something quirky in this particular setup. I’m still trying to debug this one …

 

ASP.NET AJAX Control Toolkit

Unfortunately the control toolkit experience on a Mac is pretty pathetic, however it’s pretty clear why. The Control Toolkit is largely developed by people external from Microsoft – people like Paul Glavich. Having vented to Paul quite a bit about all this lately, it became clear that him and most of his co-developers don’t actually have access to a Mac to test any of their bits – they just have to poke blindly in the dark and hope it all works. My experiences with a such an approach over the years haven’t proved very successful – there are even noticeable differences between the same version of Firefox on two different platforms. In the end I spent $80 each for two G4 Mac towers. They hum away on my local network controlled by VNC, one running Mac OS X 10.3.9 with Safari 1.3.2 and the other running Mac OS X 10.4.9 with Safari 2.0.4. When I’m out of the office, I can VNC over the the VPN.

I personally don’t understand how any professional web developer can justify not having such a setup. In the mean time though, I think the core ASP.NET AJAX team seriously needs to investigate some kind of hosted testing setup like this, with logins issued to the Control Toolkit developers. Obviously it’s a lot easier if you can point it across the local LAN to your development IIS, however a hosted setup like this accessing a CI output would still make a substantial dent in the number of Mac related bugs.

Right now I’m trying to write a patch for the CalendarExtender that puts it on the right z-index in Safari… Everything else in the extender works perfectly, you just can’t always see it.

 

The People

I do have to say, Scott Gutherie continues to amaze me as a person. He seems to be responsible for every useful chunk of developer technology getting released from Microsoft at the moment, yet still manages time to actually connect with the community, listen then actually help people out. This is a rare trait across any workplace, and requires an incredible amount of dedication.

I still love your work Scott, I just wish it’d love me back from time to time. 🙂

 

(More to come … Sorry for the delay in getting this follow-up post out; I was busy vomiting between extended periods of sleep.)