Alex Le’s Blog

Greetings:

This is the same bug I’ve come across today. If people are looking for a work around, I found a simple solution. On the servlet page where you build the list of options, include the entire select input statement.

The following example is coded in coldfusion, but can be adapted to any language.

For example, instead of using:

foo
bar

Use this:

“>
foo”>
bar”>
“>

And finally, output the variable on the servlet page:

strSelectStatement

I hope this helps.

Still trying to use the hard way of creating options elements and appending them, FF ok but ie now, this IE is really a crap. Microsoft is about marketing only. Quality NONE.

After some thinking my final vote will go for my original solution. Do innerHTML with the complete select.

Reason: speed, if you introduce only a string into your code it is really faster. But keep the appendChild in mind for special cases.

Has anyone ran into the problem where the select breaks if you put an event handler on it? For example, I added an inline onclick=”highlight()” just to change the background color of the active field. In order to select anything you first have to double-click the select for it to open and then select. Same thing when you use onfocus. Apparently, you have to use onfocusin for the select to behave correctly.

Sadly, this isn’t the only thing they haven’t patched. Have you ever tried to replace the innerHTML of a TBODY tag?

Forget it…

@Bob

My WP doesn’t seem to like your code in the comments. I think you may have to do some debugging in IE to get this straightened out. If I were you, I would put an alert() at the beginning of paintSeemsToHang() and see if the method is being fired in IE. Also, instead of just having the href=”paintSeemsToHang()”, try href=”javascript:paintSeemsToHang();”, or even try this

a href=”#” onclick=”paintSeemsToHang();return false;”

If none works, then you may have to recreate all the elements and append them to the appropriate position in the DOM, instead of using the innerHTML property.

Good luck!

http://www.goorbis.com - IE html source sniffer.

Drag the cursor on an IE page after you’ve altered it with JS, and it will show you what IE ‘thinks’ is there. It’s no developer toolbar, but it’s helped me solve a lot of IE’s crap.

Oh, thank you for your post. I was trying to solve this problem for a half of a day, and maybe would continue thomorrow, if I wouldn`t read your post.
Damn sexplorer !!!

In reference to the first problem with the selectlists and innerHTML command:
If you are able to check which browser your visitors are using in JS you can use a browser-specific javascript.
I solved it like this:

If the user has FireFox or some other browser:
document.getElementById(’SELECTLIST’).innerHTML = options;

If the user has Internet Explorer:
document.getElementById(’SELECTLIST’).outerHTML = “”+options+”"

Looks kind of crappy since what you’re doing is really to replace the called element with itself, but with the updated optionlist.

It works for me though.

[…] So here comes my first reason why IE7 sucks (or IE sucks in general): IE doesn’t have firebug. It is a firefox plug which is used for front end debugging, well, I used it for debugging my code. It has a lot of nice features like DOM element inspecting, javascript debugging where you can set up break point, watch virables and etc. I used it so much that I don’t know what I do without firebug. So under IE7 I have to actually print out everything I want to figure out what went wrong. I suffered as someone who have been using eclipse and all of sudden he has to use printf + javac to debug. Luckily that process didn’t go very far: I found that every time I try to inject code like “<option>AAA</option>” into the innerHTML via my AJAX call, for the first option it always become something like “>AAA</option>”, no matter how you define it. I did some research online and I found the solution in this blog . The freaking bug is from IE7 itself, oh wait, there is more, do you know this bug has been sitting there for a fucking 5 years from IE5(in a different format, quote needed) and nobody in Microsoft has the guts(or the knowledge, appreantly) to fix it? This is so freaking awosome. Make it suck point two for IE7. I’ve done some additional homeworks for this issue but so far seems there are two ways to solve this and neither of them is perfect, one is to use appendChild() but it will crash IE5(I’m almost speechless at this point) and not very , while the other way is to use outerHTML, and it’s not that time efficient. I finally went with the appendChild() and asked user to use IE6+. Why? because it is relatively slightly easier to code (I’m a lazy guy) and the project is an internal application, there won’t be too much diversified users, plus most of them are QA engineers at Yahoo, they have all kinds of browsers installed on their compters. […]

Looks like the comment parsed out the important bits of the regex. Another try.

var re = new RegExp(”(\<select(.*?)\>)(.*?)(\<\/select\>)”, “i”);

Thanks Adam, that worked perfectly.

Just checked a couple days ago that this bug is still present in IE8 bêta…

Today in IE7 I am trying to create a select dynamically and then insert an optoin based on user input. I am using the same code for dynamically created selects and selects in the original page HTML. Well, with selects that were not dynamically created it works fine, even in IE. But for the dynamically created select, which has a few options put in it when its created, what happens is that when another option added, using “insertBefore” method, on IE the select “length” property then changes to zero! When I changed selectedIndex, that single option will show in the combo, but it won’t drop-down (length 0). I haven’t solved it yet, i guess I will put the select into a div, and when I add another option, I’ll just recreate the entire select…. Of course, this is working fine already in all other browsers I’ve tested. Bizarre, this appears to be an IE bug specific to seletcts that were creatd using DOM methods.

You will find solutions to all your IE bugs here:

http://webbugtrack.blogspot.com/search/label/innerHTML

the Select element is only one of the elements in IE that doesn’t work properly with the DOM methods.

IE has bigger problems with innerHTML than just the select element. Setting innerHTML with certain markup [valid] throws an unknown error.
http://web.2point1.com/2008/11/12/ie-innerhtml-bug/

Site ate my HTML But it’s meant to be like this (using square brackets instead of arrow brackets):

if (document.getElementById(”sectionSelector”).outerHTML) {
document.getElementById(”sectionSelector”).outerHTML = “[select id=’sectionSelector’]” + ajax.responseText + “[/select]”;
} else {
document.getElementById(”sectionSelector”).innerHTML = ajax.responseText;
}

[…] because of its lack of support for writing to tables’ innerHTML, and Microsoft refuses to fix it. When adding an entire list to the download basket, it takes the time to download and display […]

It’s both interesting how old these bugs are and how old this blog page is, because I’m using IE 8, and I ran into the problem (and Microsoft’s workaround page) yesterday. What’s really interesting about Microsoft’s workaround page is that they recommend updating the options list programmatically instead of using innerHTML. I think pretending like a workaround is the correct behavior is a pretty lame copout for a bug.