Tested on: Linux, opt build from mozilla.org 1999-06-30-08-M8, viewer Script run while a page is loading can't set selectedIndex on a select element. (It may also not be possible afterwards if it is in a div with display: none...) Because of bug 9127, this test case is in XHTML (to be attached). In the test case, there are two select elements with three options. In one of the select elements, one of the options is selected (the first, with index 0). The script has a function that attempts to set selectedIndex to 2 in both select elements, and prints (using dump()) the actual value both before and after the attempted set of selectedIndex. The function is run while the page is loading, and it can be run again by pressing a button in the test case. While the page is loading, the following happens: * In the select element with one of the options selected, selectedIndex is 0 both before and after setting it to 2. * In the select element without any options selected, selectedIndex is -1 both before and after setting it to 2. When the function is run after the page is loaded (by pressing the button), setting selectedIndex works correctly. The statements in the text window show that it is changed to two (from 0 in both cases), and the actual elements selected shift from 0 to 2. (It is interesting to note that the selectedIndex is -1 before the select is displayed and 0 after in the second select. Should I file a separate bug on this?)

Checking if this was fixed with yesterday's checkin (should be...)

It is fixed for both GFX and native selects.

David, did you ever report the 'selected index starts off as -1' bug separately? What do you think the correct behaviour should be?

I didn't file it separately. I'd want to check if it still exists, first.

It does still exist. :S

I got a XML parsing error with the old test case, attached same in html. And what the heck, just for fun, I'm checking in a fix for this bug too... :)

Checked in that fix. To verify, visit the attachment. You should see: before changing, selectedIndex is 0 after changing, selectedIndex is 2 Twice. None of this "before changing, selectedIndex is -1" stuff. :)

This

You don't want to investigate why all but the first word of my above comment got cut off, do you?? Anyway, I said that this is still a problem in the XML test case, which I will reattach with the DOCTYPE removed.

Moving non-critical bugs out.

After careful consideration, I've decided that I probably won't get this bug in for M12. Currently I have nearly 50 bugs scheduled for M13, so there is a possibility that this bug may need to be moved out farther still.

Marking [TESTCASE].

Moving to M16. In general, JavaScript should not try to access the contents of a page while the page is still loading because there are not guarantees what state the page is in. JS that accesses page contents should do so from within the onload event handler at the earliest. This is inherently risky JS. Therefore, moving to M17 as low priority.

Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!

The HTML test case works for me. The XML test case causes a crash: ... SetHTMLSelectElementProperty (cx=0x8294838, obj=0x83b4ca8, id=-3, vp=0xbfffdc00) at nsJSHTMLSelectElement.cpp:327 nsHTMLSelectElement::SetSelectedIndex (this=0x844b6f0, aIndex=2) at nsHTMLSelectElement.cpp:621 nsHTMLSelectElement::GetPresState (this=0x844b6f0, aPresState=0xbfffd1cc, aValueArray=0xbfffd1d0) at nsHTMLSelectElement.cpp:867 nsGenericHTMLElement::GetPrimaryPresState (aContent=0x844b6fc, aStateType=eSelectType, aPresState=0xbfffd110) at nsGenericHTMLElement.cpp:1976 PresShell::GetHistoryState (this=0x83c21d8, aState=0xbfffd0b0) at nsPresShell.cpp:2473 unsigned int ns_if_addref<nsILayoutHistoryState *> (expr=0x835cf70) at ../../../../dist/include/nsISupportsUtils.h:1090 CC'ing Rod because I think he was fixing things in this area recently.

This is a problem wiht the mHistoryState data member of the PresShell. I changed the example of to be a input typ=etext and it crashed just as did for for the select. The first time it gets the history state it creates one, the second time it crashes on the addref after the assignment to the out param. What's odd is the pointer addresses of the PreShell and the mHistoryState look ok. So I don't think this is specific to any particular control. I think the mHistoryState is getting trashes somehow.

Hm, I see. I wonder if the mHistoryState has been NS_IF_RELEASED one extra time somewhere, I seem to recall something about NS_IF_RELEASE not resetting the pointer to null... Thanks Rod.

This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.

Mass update of qa contact

QA contact Update

Updating QA contact to Shivakiran Tummala.

attachment 46413 [details] shows another bug with selectedIndex. This is a small testcase that will display an alert() with the current selectedIndex on a SELECT form item. It shows that this property is not set up correctly on mozilla 0.9.3 It's okay on netscape 4 and IE5

I thought I remembered reading where having script buried in the html isn't really vaild, even though done almost everywhere (I'll have to check again). For what it is worth, an onload handler does work correctly: <html> <head> <script language="javascript"> function doload() { alert('selected='+document.eenform.sel1.selectedIndex); } </script> </head> <body onload="doload()"> <form name="eenform" action="test.html" method="GET" > <select name="sel1"> <option value="bleh">bleh</option> <option value="blah" SELECTED>blah</option> </select> <input type="submit" value="Verstuur"/> </form> </body> </html> I doubt this will be fixed for a long time.

This would be fixed by making forms store data in the content model, which I think is something that should be done in the near future, since it would fix large numbers of bugs and vastly simplify the numerous hacks in the printing code to get forms to print correctly.

Ya, das ist the plan for bug 34297 :) Select is priority 1 since that's holding up my initial patch (big annoying problems).

Fixed in forthcoming patch for bug 34297. Setting dependency.

Bulk reassigning form bugs to Alex

Fixed with the bug 34297 patch.

verified 2001-09-09