Closed Bug 12599 Opened 25 years ago Closed 25 years ago

[4.xP]invalid attribute syntax causes form submission problem

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: david, Assigned: pollmann)

Details

(Whiteboard: [patch])

Attachments

(1 file)

Test case
435 bytes, text/html
Details 
folowing code doesn't seem to get passed on to the next form
<INPUT type ="radio" name ="what" value ="mod" checked>
Whiteboard: [MAKINGTEST] Antti.Nayha@oulu.fi
Assignee: karnaze → kmcclusk
Reassigning to Kevin.
Status: NEW → ASSIGNED
Target Milestone: M10
Target Milestone: M10 → M11
Moving to M11
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
I tried the following with a Sept 1, 1999: 4:42PM build and it works.
There was a bug fixed recently with posting form data. So maybe that was causing
the problem. Marking as worksforme.

<HTML>
 <BODY>
   <FORM method="get">
     <INPUT type="radio" name="what" value="mod" checked>
     <INPUT type="submit" name="submit" value="submit it">
   </FORM>
 </BODY>
</HTML>
Status: RESOLVED → VERIFIED
Status: VERIFIED → REOPENED
tried it today again with nightly build  1999-10-03-20-M10/
got again the problem that the value of the radio button didn't get passed
the server against wich it is tested is a netscape enterprise 3.5.1C and
coldfusion app server on solaris

i will try to find a better example
Resolution: WORKSFORME → ---
Clearing WORKSFORME resolution due to Reopen.
i did some more testing and not a single form value is passes on
 below is the test code i used :
-----
<form action="moz2.cfm" method="post" name="formname"><br>
<input type="text" name="text" value="text"><br>
<input type="hidden" name="hidden" value="hidden value"><br>
<textarea cols= rows= name="freetext">freetext</textarea><br>
<input type="radio" name="radio" value="radiovalue"><br>
<input type="checkbox" name="checkbox" value="checkbox value"><br>
<input type="submit">
</form>

----------------
on the second page moz2.cfm is just the debug information wich includes the
form fields
using netscape 4.7  the result is the folowing
------------
Parameters

Form Fields:

FREETEXT=freetext
RADIO=radiovalue
HIDDEN=hidden value
FIELDNAMES=TEXT,HIDDEN,FREETEXT,RADIO,CHECKBOX
CHECKBOX=checkbox value
TEXT=text

with mozilla nothing at all
Status: REOPENED → ASSIGNED
Target Milestone: M11 → M12
Changin milestone to m12
Assignee: kmcclusk → pollmann
Status: ASSIGNED → NEW
I tried changing the form method to get instead of post and I see the contents
of the form are encoded within the URL.

This appears to be related to posting only.

Eric, can you take a look?
Summary: m9 doesn't seem to pass on the name attribute of an radio input tag → name attributes of forms are not correcly passed on in post operations
changed the summary to a better one
Status: NEW → ASSIGNED
OS: Windows NT → All
Hardware: PC → All
Posting and getting this form work in M11.  There is a problem with the
checkboxes and radioboxes though.  I'm seeing this assertion fired when loading
the page:

1024[80803f0]: Assertion: "not an int value" ((mUnit == eHTMLUnit_Integer) ||
(mUnit == eHTMLUnit_Enumerated) || (mUnit == eHTMLUnit_Proportional)) at file
../../../../dist/include/nsHTMLValue.h, line 97
1024[80803f0]: Break: at file ../../../../dist/include/nsHTMLValue.h, line 97
Break: at file ../../../../dist/include/nsHTMLValue.h, line 97

And they don't submit anything.  I got:
text=text
hidden=hidden value
freetext=freetext
for both posting and getting the form.
Forgot to mention, when I checked radio and checkbox inputs, the submitted
values for post were:
text=text
hidden=hidden value
freetext=freetext
radio=radiovalue
checkbox=checkbox value

The asserts are caused by the the "cols= rows=" attributes to the textarea.
Assignee: pollmann → harishd
Status: ASSIGNED → NEW
Summary: name attributes of forms are not correcly passed on in post operations → invalid attribute syntax causes form submission problem
Harish, this seems like it is just bad HTML - we talked about this briefly but I
can't remember deciding on a solution.  Can you take a look and decide if it
would be sane to correct this:

<TEXTAREA COLS= ROWS= NAME="Foo">Test</TEXTAREA>

If not, I think it's ok to call this invalid HTML => invalid bug.
P.S. to the original bug reporter.  If you are interested in why ColdFusion may
not be happy with your form submission, I highly recommend reading bug 7533.
Bug 7533 was fixed about a week ago, but if you are using builds from before
then you may still experience problems.
i'm not agreeing with you on the fact that this should become an invallid bug

there are lot's of pages with code like this

i allready seeing myself explaining this to my user : "yes the page has invallid
code that's why it crashes"

this is realy a bug mozilla should be able to handle invallid code just like
netscape 2 - 3 and 4 did
Summary: invalid attribute syntax causes form submission problem → [4.xP]invalid attribute syntax causes form submission problem
QA Contact update.
Assignee: harishd → pollmann
Eric -- I'm reassigning this to you, since I provided you a patch which fixes
the problem. Thanks.
Whiteboard: [MAKINGTEST] Antti.Nayha@oulu.fi → [patch][MAKINGTEST] Antti.Nayha@oulu.fi
Will shoot for M13, the updated routine as provided by Rick is:

inline PRInt32 nsHTMLValue::GetIntValue(void) const
{
  NS_ASSERTION((mUnit == eHTMLUnit_String) ||
               (mUnit == eHTMLUnit_Integer) ||
               (mUnit == eHTMLUnit_Enumerated) ||
               (mUnit == eHTMLUnit_Proportional), "not an int value");
  if ((mUnit == eHTMLUnit_Integer) ||
      (mUnit == eHTMLUnit_Enumerated) ||
      (mUnit == eHTMLUnit_Proportional)) {
    return mValue.mInt;
  }
  else if(mUnit == eHTMLUnit_String) {
    PRInt32 err=0;
    return (mValue.mString) ? mValue.mString->ToInteger(&err) : 0;
  }
  return 0;
}
Attached file Test case — 

    
  
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED

    
    

    
  
I just checked in the changes Rick provided with no changes.  This did a
wonderful job of removing the assert.  Thanks Rick!

To verify the fix, go to the attached test case:
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=4016

And click on the submit button.  You should not see an assert (on Windows this
means that no dialog box will come up, on UNIX it means no error message will be
printed to the console).  Thanks!

    
  
Status: RESOLVED → VERIFIED
Whiteboard: [patch][MAKINGTEST] Antti.Nayha@oulu.fi → [patch]

    
    

    
  
Verifying fixed on 2000010908 build / WinNT4 SP6.
Component: HTML: Form Submission → DOM: Core & HTML

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: