ASP.NET AJAX … continued

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.

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:

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.

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.)

8 thoughts on “ASP.NET AJAX … continued”

So we do test the Toolkit on Safari via a VPC like setup – it’s 2.0.4. We don’t have an easy way to expose that setup to our contributors (trust me, getting something setup here at MS that is accessible via the outside world is a major operation). But the internal folks here do go through a test pass on all of the components (including contributor ones) on Safari and then we either fix the issues ourselves or go back to the contributors.

What we have not been doing is tesing FF on Mac, hmmm.

For the issues that you’re seeing, are you filing them on the Toolkit CodePlex project and/or submitting patches?

Maybe Apple’s release of Safari for Windows will help windows developers without access to OSX machines http://www.apple.com/safari/ going forward, or maybe it will just lead to a slew of “it works fine on Safari 3.0.1 on Windows but not on Safari 3.0.1.2 on OSX” type issues.

Thanks for the report, and as Shawn said, sorry to hear you’re having trouble. We are looking into the UpdatePanel issue and will get back to you soon.

In terms of the 2.0 browser, you’re correct, we do only support 2.0.4, and the documentation is incorrect. Earlier versions of 2.0 had some issues that kept UpdatePanel from working in most scenarios, so we disabled it.