Closed Bug 3340 Opened 26 years ago Closed 25 years ago

compatibility: indexing into select for options.

Categories

(Core :: DOM: Core & HTML, defect, P2)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 2195

People

(Reporter: morse, Assigned: pollmann)

References

(
URL
)

Details

The following content gives the correct values for the alert when run under 4.5 browser but gives incorrect values in 5.0. Specifically: selectName.selectedIndex: 4.5 = 0 5.0 = -1 selectName[0].value: 4.5 = option1 5.0 = <javascript error> Note: This might be the same bug as 3285 but until someone makes that determination I am filing this as a separate bug report. Bug 3285 involved frames filled in dynamically by javascript's document.write whereas this bug involves frames that exist from the start. I was trying this as a work-around to bug 3285 thinking that the dynamic frames might have been the problem. Let me stress that these two bugs are currently blocking problems in developing the client-side wallet application. <HTML> <HEAD> </HEAD> <BODY> <FORM name=formName> <TABLE> <TR> <TD> <SELECT name=selectName> <OPTION VALUE=option1 SELECTED> one </OPTION> </SELECT><BR> </TD> </TR> </TABLE> </FORM> <SCRIPT> alert(document.formName.selectName.selectedIndex); alert(document.formName.selectName[0].value); </SCRIPT> </BODY> </HTML>
Assignee: norris → vidur
This is almost certainly in the DOM, not JavaScript.
Assignee: vidur → pollmann
Eric Pollmann is the right guy for DOM forms related bugs. Eric, Steve Morse is blocked by this bug.
URL: http://blueviper/forms/selectarray.html
Status: NEW → ASSIGNED
The selectedIndex problem is indeed a bug. I'm on it. However, according to the DOM spec, you can not access the options array by indexing directly into the select element. Your javascript should read: selectName.options[0].value and NOT selectName[0].value This works in both 4.5 and 5.0 - is this an acceptable solution for that portion of the problem?
More info on the selectedIndex bug: You can work around this bug for the time being using a body onload tag. For an example, see the above URL. The DOM gets the selectedIndex by querying the frame, which has not been created yet when your script is executed. I'll change the select element to use the options array to determine the selectedIndex in the case that the frame is not yet created.
I just checked in a fix to the selectedIndex problem.
Severity: major → normal
Summary: javascript gives wrong selectedIndex for a list → compatibility: indexing into select for options.
Since indexing into the select to get options is a compatibility issue, I'm marking it as such.
per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
DOM bugs are not my problem.
QA Contact: 4015 → 4616
QA contact re-assigned according to the product areas we're currently working on.
Target Milestone: M7
Component: JavaScript → DOM Level 0
Moving to DOM Level 0 component. Move to DOM Level 1 if that is more correct.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Since the only remaining issue here is treating select[n] the same as select.options[n], this is a dup of 2195. *** This bug has been marked as a duplicate of 2195 ***
Status: RESOLVED → VERIFIED
Duplicate of Bug# 2195.
You need to log in before you can comment on or make changes to this bug.