Closed Bug 2999 Opened 26 years ago Closed 26 years ago

OPTION elements with value="" are treated as if the value was not set at all

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: sdm, Assigned: pollmann)

References

(
URL
)

Details

This is for compatibility with previous versions of navigator. If you go to the above address, and submit the form without filling out the form, the value of the S value (State), is given as Choose+a+State, which is the contents of the OPTION element, not the value, which is set as value="". In navigator 4.x, the value is set to null, not the contents of the OPTION element. The w3 spec on this issue is a little vague: http://www.w3.org/TR/REC-html40/interact/forms.html#adef-value-OPTION It states that if the value is not set, it is then set to the contents of the OPTION element. But it does not say what should happen if it is set to null.
per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
QA Contact: 4110 → 4137
Reassigning qa contact to cpratt@netscape.com
cpratt, is this on ALL platforms?
I can't see what's happening here on all platforms. On Windows 98 and NT, according to the information the DOS window, this problem is still happening. It says: data=?SRC=&STYPE=S&PG=L&C=&N=&T=&S=Choose+a+State&R=N&search=Find+It I've tried changing the form action to use a mailto: url to see what's going on other platforms, but that isn't working yet.
Target Milestone: M6
Here's another, reduced test case: http://blueviper/forms/selectnullvalue.html <HTML> <BODY> <FORM METHOD="get" ACTION="/cgi/echo.cgi"> <SELECT NAME="NullSelect"> <OPTION VALUE="">Null value <OPTION>No value attribute </SELECT> <INPUT TYPE=SUBMIT> </FORM> </BODY> </HTML> The solution is to check the result of the GetOption method to see if it returned NS_CONTENT_ATTR_HAS_VALUE rather than to check to see if the string length returned is 0. The problem with that solution is that right now, the macro NS_IMPL_STRING_ATTR returns NS_OK regardless of what mInner.GetAttribute returns (it's not passing though a success code). We can't change that unless all of the generated DOM string getter methods use NS_SUCCEEDED instead of comparing to NS_OK, as it would break, um, a lot of things.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Just checked in a fix: Using GetHTMLAttribute instead of GetValue. :) (thx Vidur)
Status: RESOLVED → VERIFIED
I believe this is fixed. 1999052408 build, NT.
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.