183940 - [FIX]document.formname.name doesn't work for radios with ID

Status: RESOLVED FIXED

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

Description

[Steven Bryant]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130

Hello-

When at the page http://bigcharts.marketwatch.com/symbollookup/symbollookup.asp
I am unable to perform a "Search For Symbol" using Mozilla 1.2.1.  I am able to
perform this action with IE.  I have verified this behavior on two different
computers - one running Windows 2000 and the other running Windows XP.  

What happens on this page is that you should be able to enter a company name in
section 1.  For example, I chose "Rational".  I did not change any of the radio
button selections in sections 2 or 3.  Section four consists of a image that
should be pressed to begin processing the page.  In Mozilla 1.2.1, pressing this
image has no effect.  Because I have been able to consistently recreate this
behavior, I believe you will also be able to so so at this URL.

As I am no longer a developer (it's been a few years), I don't know if this is a
coding problem with the Site's JavaScript, or if it is something within Mozilla.
 So, I thought I'd report it.  As a new bug reporter to Mozilla, I am hoping
that this is not a duplicate entry.  I reviewed the other entries, but did not
see anything that was an obvious duplicate.

If you have any questions, please feel free to e-mail me.

Best Regards,
Steven

Reproducible: Always

Steps to Reproduce:
1. Navigate to http://bigcharts.marketwatch.com/symbollookup/symbollookup.asp
2. Put the name of a company in field 1 (e.g., Rational)
3. Press the "Search For Symbol" graphic associated with step 4.

Actual Results:  
Nothing.

Expected Results:  
It should have brought up a results page.  In this case, the page will be for
Rational Software and will consist of a graphical chart as well as stock pricing
information.

Comment 1

[Stefan [:stefanh]]

Confirming with Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.2.1) Gecko/20021130

From what I understand onmousedown is supposed to invoke a JS function called
"searchresults"

<img src="images/symbolsearch.gif" onmousedown="searchresults()">

In my JS console i see the following message after i pressed the image:
Error: opt2[i] has no properties
Source File: http://bigcharts.marketwatch.com/symbollookup/symbollookup.asp
Line: 52

I'm not sure if thats the reason why it doesn't work, but opt2[i] comes from the
function searchresults():

function searchresults(){	
var page = '/symbollookup/symbollookupresults.asp?';
var symb = document.notfound.symb.value;
symb = symb.replace(/ /g, "%20");
var opt= document.notfound.radio1;
var opt2=document.notfound.radio2;

for (var i = 0;i<opt.length; i++)
		if(opt[i].checked)
			break;
countrycodes = opt[i].value;

if(countrycodes=="")
 {
 countrycodes = 'all';
}


for (var i = 0;i<opt2.length; i++)
		if(opt2[i].checked)
			break;
type = opt2[i].value;

if (countrycodes != "us")
{
if (type != "all"){
alert('This data is only available for United States issues.Your selected
security type has been changed to "all".');
type = "all";
}
}

var URL = page + 'symb=' + symb + '&country=' + countrycodes + '&type=' + type;
window.location.href = URL;
return false;
}

Comment 2

[Mikael Parknert]

Reporter: Can you reproduce this bug with a recent build of Mozilla (for
example, 1.4rc3)? 

If so, then please comment again with details. 
If not, then please resolve this bug as WORKSFORME. Thanks.

Comment 3

[Steven Bryant]

Retested on July 13, 2003.  Problem still occurs as described in the problem
report on release 1.4.  - SBB

Comment 4

[Stefan [:stefanh]]

I can confirm the issue with a Camino nightly build (2003071004) on Mac OS
10.1.5. This works in IE5.1 for Mac OSX.

Comment 5

[Jesse Ruderman]

Attachment: testcase

The problem is in these lines:
<input id=radio2 name=radio2 type="radio">
<input id=radio2 name=radio2 type="radio">

If type="radio" is the first attribute instead of the last, it works correctly!

Comment 6

[Jesse Ruderman]

Confirming: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a)
Gecko/20030702 Mozilla Firebird/0.6

-> DOM 0

Comment 7

[Boris Zbarsky [:bzbarsky]]

Attachment: Proposed patch

There are actually two bugs here.

The first hunk fixes the first bug -- screwing up a check for whether a node is
already in form.name.  That fixes the first two sets of radio buttons in
Jesse's testcase, but makes the third set only show up as a single control
instead of a list.

The second hunk fixes that issue -- the code that removes the control from the
list when type is changed (via the content sink) was not checking to make sure
that the control it's removing is the one it got passed.  So the double-removal
(once on name and once on ID) removed both controls from the list.  Then the
one control whose type was being changed got readded...

Anyway, that testcase passes completely with this patch.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 136155 [details] [diff] [review]
Proposed patch

jst, would you review?	I think we want this for 1.6, so...

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: Actually, maybe this is slightly better

Comment 10

[Boris Zbarsky [:bzbarsky]]

Taking.

Comment 11

[Johnny Stenback (:jst)]

Comment on attachment 136156 [details] [diff] [review]
Actually, maybe this is slightly better

-      PRInt32 oldIndex = -1;
-      list->IndexOf(newChild, oldIndex);
-
+      PRInt32 oldIndex = list->IndexOf(newChild, PR_FALSE);

Nice! I hope some compiler would've caught that...

r+sr=jst

Comment 12

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 136156 [details] [diff] [review]
Actually, maybe this is slightly better

Could this please be approved for 1.6b?  This is a very safe patch that just
fixes two very obvious logic errors in the handling of form.foo lists....

Comment 13

[Boris Zbarsky [:bzbarsky]]

Fixed for 1.6b