Internet Explorer SELECT element bugs, test suite

Bug index:

  1. Bug: programmatically setting selections on a multiSELECT elements (<SELECT multiple>) doesn't update value/selectedIndex properties, nor fire onChange event
  2. Bug: resetting a SELECT element doesn't fire onChange or onPropertyChange event
  3. Bug: SELECT elements with relative font-sizes are misrendered when changing text-size
  4. Bug: "windowed element" z-index problem
  5. Bug: setting SELECT elements' innerHTML property fails
  6. Bug: when disabled, events don't fire





1. Bug: programmatically setting selections on multiSELECT elements (<SELECT multiple>) doesn't update value/selectedIndex properties, and doesn't fire onChange event

Summary: Several problems with MultiSELECTs (<SELECT multiple="true">) here...
Related docs: ??
Suggested Workarounds: ??

Bug demo:










2. Bug: resetting a SELECT element doesn't fire onChange or onPropertyChange event

Summary: resetting a form (either with a standard reset button or by a programmatic reset method call) never fires a contained SELECT's onChange or onPropertyChange events. Related docs: ??
Suggested Workarounds: ??
  1. Choose any option (the onChange and onPropertyChange alerts show)
  2. Click either reset button (NO alerts show)

Bug demo:







3. Bug: SELECTs with relative font-sizes are misrendered when changing text-size

Summary: IE (v6, and presumably older versions) fails to correctly re-draw multi-line SELECT objects with relative font-sizes when changing the page's text-size (View menu > Text Size > any other size).  It maintains artifacts of the original rectangle's visual contents over top of the new rectangle.
Screenshots: bug (in IE6)
Related docs: ??
Suggested Workarounds: ??

Bug demo (relative font sizes):

plain:
size="4": multiple:

(The fieldset around the culprits doesn't affect the phenomenon.)

Reference demo (non-relative font-sizes):

plain: size="4": multiple:



4. Bug: SELECT elements ignore Z-index ("windowed element" problem)

Summary: SELECT elements ignore their and other elements' CSS z-index positioning property.
Screenshots: bug (in IE6), right (in FF)
Related docs: KB177378 - How the Z-index Attribute Works for HTML Elements
3rd-party Workarounds: <SELECT>-Free Layer (CSS-only hack)

Bug demo:

This box has explicit relative positioning and z-index of 9.  It should be above the SELECT elements.
The first 2 SELECTs have no positioning or z-index set (implicit z-index of 0).
The second two SELECTs have explicit relative positioning set and z-index of -9.




5. Bug: setting SELECT elements' innerHTML property fails

Summary: If you set the innerHTML property of a SELECT element (a way to add OPTION tags that's much faster than looping through long lists), it truncates the first OPTION tag in the string and makes the SELECT appear blank
Related docs: KB276228 - Internet Explorer Fails to Set the innerHTML Property of the Select Object
Suggested Workarounds: Loop via script, or (for long lists) replace entire SELECT using outerHTML (side-effect: have to re-bind any event handlers)

Bug demo:






5. Bug: when disabled, SELECT elements' events don't fire

Summary: This may be debateable.  The HTML 4 spec says nothing about the DISABLED attribute causing events to not fire.  I guess that it doesn't explicitly say otherwise led Microsoft to assume that it does, judging by their DISABLED docs, which say "Disabled elements do not respond to mouse events".  Mozilla appears to follow that too, since Firefox behaves the same.  Unfortunately, this can a be a real development pain, (it's easy to script a check which ignores events when disabled, but we can't add events that aren't there...)
Related docs: HTML 4 DISABLED spec, MSDN DISABLED doc
Suggested Workarounds: Fix the browsers??

Bug demo:



Enabled:


Disabled:




Documentation originally created 2004-09-24, by Rob Eberhardt @ Slingshot Solutions