Closed Bug 9136 Opened 25 years ago Closed 23 years ago

problems setting selectedIndex before list displayed [form sub]

Categories

(Core :: Layout: Form Controls, defect, P3)

defect

Tracking

()

VERIFIED FIXED
Future

People

(Reporter: dbaron, Assigned: alexsavulov)

References

Details

(Keywords: dom1, testcase, Whiteboard: [TESTCASE])

Attachments

(4 files)

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?)
Assignee: vidur → pollmann
Checking if this was fixed with yesterday's checkin (should be...)
Status: NEW → RESOLVED
Closed: 25 years ago
OS: Linux → All
Hardware: PC → All
Resolution: --- → FIXED
Target Milestone: M11
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
Attached file Same test case, html
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.  :)
Status: RESOLVED → REOPENED
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.
Resolution: FIXED → ---
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.
Whiteboard: [TESTCASE]
Marking [TESTCASE].
Target Milestone: M13 → M17
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!
Keywords: testcase
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.
Status: REOPENED → ASSIGNED
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.
Target Milestone: M17 → Future
Mass update of qa contact
QA Contact: gerardok → janc
Keywords: dom1
Component: DOM Level 1 → DOM HTML
QA contact Update
QA Contact: janc → desale
Updating QA contact to Shivakiran Tummala.
QA Contact: desale → stummala
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
Component: DOM HTML → HTML Form Controls
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.
Depends on: 34297
Bulk reassigning form bugs to Alex
Assignee: pollmann → alexsavulov
Status: ASSIGNED → NEW
Summary: problems setting selectedIndex before list displayed → problems setting selectedIndex before list displayed [form sub]
Fixed with the bug 34297 patch.
Status: NEW → RESOLVED
Closed: 25 years ago23 years ago
Resolution: --- → FIXED
verified 2001-09-09
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: