views:

1702

answers:

3

This may sound crazy, and i didnt believe it until i saw it for myself.

The vertical scroll bar does not scroll when you click in the space between the scroller or the arrows. You have to drag the bar to get it to scroll. This only happens in the ugly default theme (not windows classic).

The scroll bar has some heavy javascript behind it that drive scrolling of another DIV on the page.

Has anyone even encountered this before? Why the heck does the theme influence IE's rendering?! Only IE!

edit: this problem happens when you are in "non-classic" XP theme (the default ugly one). switching themes does not cause this, but it does fix it if you switch to classic from the default.

A: 

First, I'll start saying that IE is a terrible browser and in some cases you don't have control over issues while developing a web application.

In that case I haven't encounter such an issue and a Google search don't pull anything on the subject. I'd say it must be something in your code that lead to a weird bug. Most likely it won't break in a lot of systems, so unless it's a very important application (sales, government...) you could leave it that way.

Look at it that way: who change the style of windows to classic? Geeks. And do geeks use IE? No. ^^ ... Joking, but not really.

If it's important I'll need to take a look at your actual code for "The scroll bar has some heavy javascript behind it that drive scrolling of another DIV on the page."

marcgg
I have seen a lot of managed corporate deployments of Windows XP that disabled themes and sometimes also force "classic start menu". There are 2 reasons: 1) there is some memory/processing overhead to themes so without it they can deploy cheaper computers and 2) they don't have to train people how to use the XP start panel which would entail writing up manuals and sending people to classes. Seriously. These same organizations invariable have IE6 deployed. They will have a policy to use the current default Windows browser, which is IE6 on XP.
Brian Reiter
+1  A: 

In order to avoid certain Windows restrictions, IE re-implements almost all the controls visible on a web page.

The Old New Thing : Windowless controls are not magic

<excerpt>

The Internet Explorer team went and reimplemented all of the controls that a web page would need. They have their own windowless checkbox control, a windowless listbox control, a windowless edit box, and so on. In addition to reproducing all the functionality of the windowed controls, the Internet Explorer folks also had to reproduce the "look" of the windowed controls, down to the last pixel. (Functions like DrawThemeBackground and DrawFrameControl prove extremely helpful here.)

If I recall correctly, the only element that is still windowed is the <SELECT> element.

If you squint, you can see some places where they didn't quite nail it. For example, if you right-click in a text box, options like "Right to left reading order" and "Insert Unicode control character" are missing. As another example, notice that IE's scroll bars do not light up when you hover over them.

</excerpt>

Without seeing the code implementing your page, I would guess that this is another manifestation of "IE's controls don't act native".

If you have a support contract with Microsoft, I'd suggest complaining to them through that channel; if not, see if you get any responses in the microsoft.public.internetexplorer.general newsgroup. Back in IE6, they broke the scrollbar with KB824145 and fixed it with KB832894, so it's not like theses sorts of problems haven't happened and been resolved before.

ephemient
+3  A: 

Does it help when you add

<!--[if IE]><meta http-equiv="MSThemeCompatible" content="no"><![endif]-->

to your page source? It worked well to work around glitches in IE when a non-classic theme is enabled for me. Note that the conditional comments are there so that firefox does not parse the tag (because it will screw up scrollbars in firefox sometimes).

mihi
Hey, it worked!
mkoryak