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