From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; 0.8) Gecko/20010215 BuildID: 2001021508 If your html form contains hidden fields and the user submits the form, the hidden fields and their values ARE NOT SUBMITTED to the server. For example, say your <FORM> has the following element: <input TYPE="hidden" NAME="STEP" VALUE="LOGIN"> With Netscape 3.x,4.x and all versions of IE, the variable "STEP" would be sent to the server with a value of "LOGIN". This does not happen with the current build of Mozilla 0.8. Our app uses this, so it flat out does not work in this browser. Reproducible: Always Steps to Reproduce: Easy. Create a form with a hidden field with a value, submit it to your servlet (or whatever), and see if it is there. If you want, go to our website at www.aag1.com. Click on the Vehicle Tracking button. Then click the Login button on the form that pops up. Type in any userid/passord, and you get the message that an unexpected error has occurred. This is happening because it does not know what STEP is being performed, which is hard-coded through hidden fields in each page that calls ther servlet. Actual Results: As stated above, the app errors out because the STEP variable and it's contents were not passed to the servlet. Expected Results: A STEP variable with value "LOGIN" is passed, and your entered userid/password is checked. For an unregistered user, this would result in being sent back to the login page with a red error message stating that the user id could not be found. A registered user would be taken to our main menu. This is very easy and straighforward to reproduce.

The relevant code from the page: <table CELLPADDING="1" CELLSPACING="-1" COL="5" WIDTH="33%"> <caption><b></b><caption> <input TYPE="hidden" NAME="STEP" VALUE="LOGIN"> <tr ROWSPAN="2"> Making the second <caption> be </caption> fixes the problem quite nicely (though the resulting HTML is still illegal -- <input> should not be outside <td> but we're correcting for that). Note that if the second <caption> is removed (ie we just have _one_ unclosed caption), we deal OK. Over to parser to decide whether this is worth special-casing. John, you may want to consider just adding that / to make this work with Mozilla, since that / should be there anyway.

updated qa contact.

Anyone from the parser can say whether we should nominate this for navquirks? this page is too buggy imho and I would send it to evangelism. Will do so if I get no feedback

Uhmmm, this is wacky.......but will take a look anyway ( probably in the content sink ) to understand the problem.

The parser ( did prevent caption from nesting) and the sink ( did attach INPUT to the corresponding FORM ) seem to be doing the correct thing. AFAIK, this is either a bug in TABLE code or in the FORM submission code. Giving bug to pollmann & ccing karnaze, rods & myself.

*** Bug 69047 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of 34297 ***

The hidden inside <caption>'s does not have a frame created, so it is equivalent to having display:none... Marked dup of the display:none bug.

HTML Form controls issue. Assigning it to vladimire@netscape.com.

I cannot reproduce this, although the duplicate bug is open. is this really a dupe?

Yes, still a duplicate. See the updated test case. When submitted, you should see: * msg1 * hello * msg2 * there Instead, you will only see * msg2 * there This is because the first hidden input is not getting a frame created for it, and therefore not getting submitted to the server. The bug this was marked a duplicate of is about "form controls that don't have a frame (display:none) don't get submitted to the server" also.

aha. Verifying