Closed Bug 2282 Opened 26 years ago Closed 25 years ago

form element in tbody is positioned wrong

Categories

(Core :: Layout: Tables, defect, P2)

x86
Windows NT
defect

Tracking

()

VERIFIED DUPLICATE of bug 1399

People

(Reporter: rickg, Assigned: harishd)

Details

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>
Assignee: buster → rickg
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.)
Assignee: rickg → buster
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?
Status: NEW → ASSIGNED
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
Assignee: buster → karnaze
Status: ASSIGNED → NEW
Chris:  somehow, a couple of table bugs slipped through my filter.  reassigning
to you.
Assignee: karnaze → harishd
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
Closed: 25 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 ***
Status: RESOLVED → VERIFIED
Verified bug dup of #1399
You need to log in before you can comment on or make changes to this bug.