Searching the web, I found an article by Damien White discussing his his same pains with this. His solution involved using the IE-specific CSS “expressions” to calculate the height and width of the window.

height:

expression(

document.documentElement.scrollTop +

document.documentElement.clientHeight + “px”);

width: expression(document.body.clientWidth + “px”);

However, at least for me, Damien’s expressions wouldn’t handle scrolling down the page.

Damien explains:

The thinking behind this was to take the window height (which document.documentElement.clientHeight gives us) and then add the scroll top position, which will give us the upper portion if the user scrolls up. The problem shows itself when the user scrolls down; that area is not covered. The good thing about this is that I didn’t need to mess with the body height, but the solution isn’t optimal in the long haul.

That’s a bad deal because that’s the whole point! Reading a bit more, there was a comment from Kunal Mukherjee on Damien’s post that solved the problem.

Kunal’s expressions looked at the scrollHeight of the window as compared to the offsetHeight and returned the larger.

I also included !important flags on each of the properties in the ie6.css file—just to be safe.

Issue #2 – IE6 Pushes <SELECT> tags above everything else…

This is where the solution gets dicey; however, I’m relying on Kunal’s solution again. In his comment, he pointed out a way to hide <SELECT> tags in IE6 without causing the disappearing act that the ModalPopupExtender causes—cover them with an IFRAME.

To me, this hack seems… sketchy at best, but it works.

In the ProgressTemplate of the UpdateProgress control, add in the IFRAME.

You mean the actual .css file? I can find and send it to you if you’d like; however, the relevant code is here and the file I was working with had about 120 other styles in it that were nonpoint to the fix. In the end, it was too fragile to reproduce this time and time again–I ended up wrapping it up in a control: