Home > WTF > Why I hate Internet Explorer or the story of the asynchronous combo box that couldn’t fly

Why I hate Internet Explorer or the story of the asynchronous combo box that couldn’t fly

I’m working on a project that has some performance issues. One them is one single page that takes more than a minute to show. I analyzed what was going on and the truth was that the page’s size was about 3.5 mb. So, what was making the markup so large? comboboxes. Seventeen comboboxes with about 600 options average (but there was some with 2000 options!).
My first reaction was “Why in the hell they need a combobox with 2000 options? this is a functional failure”. But you know, “it’s what the client wants, it’s too late for chaning it now”.

The first solution we came with was to render only the selected value in the markup and to populate the entire list using ajax when the user clicks/focuses on the combo. The great about it is that the ajax responses could be cached by the server side for reducing the server processing and by the browser, so there’s no need to go find the same items again. Just lovely.
And it worked, and worked fine. Except for Internet Explorer. For some reason, if you change the options collection, the select will close, so the user have to click it again.
IE Fail

Our second approach was to call the populate method when the page loading is complete (aka document.ready). The idea was to have the user filling the form while the combos where loading. And, of course, we could make use of the sweet cache I told before. Well, loading about 9000 options will crash your browser. In this way, it takes more time than the 3.5 mb page! So we moved from adding options using the DOM to use innerHTML, so we can change all the options in one shot. It works perfect in firefox, but for internet explorer… well… This code:

var combo = document.getElementById("combo");
combo.innerHTML = "<option value='1'>Test1</option><option value='2'>Test 2</option>"
alert(combo.innerHTML);

Gives me this:
.
And, of course, it doen’t work. Then, I tried this approach:

var combo = document.getElementById("combo");
var option = new Option();
combo.add(option);
option.outerHTML = "<option value='1'>Test1</option><option value='2'>Test 2</option>"
alert(combo.innerHTML);

And it gives me the same result!! It just doesn’t make sense at all! At least, Microsoft is aware of it… are you kidding me? it was found in the IE 5.5 era and continues broken?

Changing the combobox outerHTML works, but we miss the reference to the previous combo in the DOM and the ASP.NET Validators stop working.

After days of Internet Explorer induced stress we decide that the problem was actually functional, and called the client. He confirmed that there shouldn’t be so many options and that there should be a configuration problem, so we limited the amount of options to 200 and start working on the configuration issues instead.

Advertisements
  1. Rodrigo
    August 3, 2010 at 3:19 pm

    Ivo, have you tried it with JQuery? http://www.jquery.com, it was developed to work just fine with Mozilla, IE, Chrome, etc.

    • ivowiblo
      August 3, 2010 at 7:45 pm

      Of course! In fact, all the ajax interaction was made using JQuery. The code example was written in plain javascript just for the sake of the explanation, but we tried the html() method (and others) and it works using innerHTML 😦

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: