View this html snippet to see the problem: <HTML> <BODY> <FORM ACTION="http://somewhere/somecgi"> <TABLE border=1> <tbody> <INPUT name="name" value="value"> <TR> <TD>Some data</TD> </TR> </tbody> </TABLE> <INPUT type="submit" value="Submit"> </FORM> </BODY> </HTML>
it looks like the table size is correct (look at debug output from the table layout strategy, or at a frame dump, or simply add a bgcolor to the table to see where it gets placed and how big it is.) my guess is that it has to do with the (heretofore unused) protocol on the content sink used by the parser to move illegal content out of the table and into the table's parent. This protocol and/or it's use is broken, and not in a way unique to form elements. Replace the form elements with text strings and the illegally-placed text string gets dropped out of the document entirely (that is, dump content shows that it is literally not in the content tree.)
Steve -- I think there's something else going on here. The parser isn't pushing content out of tables. If you look at the content sink, the input tag IS inside the tbody. What else is going on here?
Setting all current Open/Normal to M4.
per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
changed misc bugs to M6
setting my table bugs to M9
Chris: somehow, a couple of table bugs slipped through my filter. reassigning to you.
The parser is putting the 1st input (default type = text) inside the tbody. The table frame construction should have constructed an anonymous row and cell around it, but didn't for some reason. That's a different bug, and I'll file a report on that (but it is low priority, as it is CSS 2). To be compatible with Nav4.6 and IE5, the parser needs to put the 1st input outside of the table and before it. Reassigning to Harish.
Status: NEW → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → DUPLICATE
The problem is that the form elements could be opened anywhere in a document and therefore are never treated as illegal-content inside table. *** This bug has been marked as a duplicate of 1399 ***
Verified bug dup of #1399
You need to log in before you can comment on or make changes to this bug.