The DOM doesn't seem to track a select element's screen behavior. To reproduce the symptoms: 1. Have NGLayout display a form containing a two-option select element, i.e. <select name="select1"> <option value="std"> Standard </option> <option value="overnite"> Overnight </option> </select> 2. Using the list box, select the second option. 3. Now, using XPCOM, query the DOM for the index of the selected item. According to nsIDOMHTMLSelectElement's GetSelectedIndex, the first option is selected, which is incorrect. 4. If you now simply open the list box (by pressing the down arrow) and then immediately close it, nsIDOMHTMLSelectElement's GetSelectedIndex will return the correct index. Note that this is the behavior using a Win32 optimized build of NGLayout, running under NT 4.0.

Using a debug 2/24 NT build, this works ok as the following test illustrates. Recent changes may have fixed this if an older build was used. An optimized build should not be causing this. <form> <input type=button value="print selectedIndex" onclick="printSelectedIndex()">&nbsp; <input type=button value="setSelectedIndex to 1" onclick="setSelectedIndex()"> <BR> <select name="select1"> <option value="std"> Standard </option> <option value="overnite"> Overnight </option> </select> <script> var selects = document.getElementsByTagName("SELECT"); var numSelects = selects.length; function printSelectedIndex() { for (var i = 0; i < numSelects; i++) { dump("selected index = " + selects[i].selectedIndex + "\n"); } } function setSelectedIndex() { selects[0].selectedIndex=1; } </script> </body> </html>

works great on 1999-06-15-14 RedHat Linux 5.2 kernel 2.2.7 1999-06-14-09 WinNT 4.0 sp4 1999-06-15-08 MacOS 8.51