Yet another day wasted on IE

I’ve just spent more than eight hours working on a single bug in IE.

In a classic Domino web application which I work on, we have a complex form which was working just fine when we developed and tested it. But then users started reporting their Internet Explorer clients were hanging intermittently. We finally got a test case where we could reproduce the problem.

When the user selected an option from a combo box, a new row is added to a table and displayed for them to fill in some data which is required. Nothing too odd there. And again this worked fine for us, until we opened the form inside an iFrame. Our application is part of a much larger application and the end user doesn’t know that when they click a certain link they are suddenly running on a Domino server inside the iFrame.

So cue me spending a whole day assuming this was a JavaScript problem, it only seemed to happen when the onChange event of the combo box fired, if I disabled the JavaScript then it worked fine, but the hang was after the JavaScript had finished executing (at least the debugger said so). 

Then on a hunch I removed all of the CSS from the form. And it suddenly started working. It didn’t look very good of course, but at least I now just had to track down the offending line of CSS. 

In the end it turned out to be a div which wrapped around the whole page which had a class assigned that set float: left. As soon as I removed that one line of CSS the page worked absolutely fine. I still don’t really understand *why* that single change fixes the problem, but maybe it will help someone else.

So, just to recap, the symptoms we’re looking at are IE (8 in this case) hanging after an onChange event fires which causes some new HTML to be rendered into a page which is running inside an iFrame. And the solution is to examine, very closely, your CSS.

Once again I’ll say it. The quicker the world is rid of IE then the happier I will be.

Tags: bugscsshangie8iframe