form element in tbody is positioned wrong

VERIFIED DUPLICATE of bug 1399

Status

()

P2
normal
VERIFIED DUPLICATE of bug 1399
20 years ago
20 years ago

People

(Reporter: rickg, Assigned: harishd)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

20 years ago
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>

Updated

20 years ago
Assignee: buster → rickg

Comment 1

20 years ago
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.)
(Reporter)

Updated

20 years ago
Assignee: rickg → buster
(Reporter)

Comment 2

20 years ago
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?

Updated

20 years ago
Status: NEW → ASSIGNED

Comment 3

20 years ago
Setting all current Open/Normal to M4.

Comment 4

20 years ago
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Comment 5

20 years ago
changed misc bugs to M6

Comment 6

20 years ago
setting my table bugs to M9

Updated

20 years ago
Assignee: buster → karnaze
Status: ASSIGNED → NEW

Comment 7

20 years ago
Chris:  somehow, a couple of table bugs slipped through my filter.  reassigning
to you.

Updated

20 years ago
Assignee: karnaze → harishd

Comment 8

20 years ago
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.
(Assignee)

Updated

20 years ago
Status: NEW → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → DUPLICATE
(Assignee)

Comment 9

20 years ago
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 ***

Updated

20 years ago
Status: RESOLVED → VERIFIED

Comment 10

20 years ago
Verified bug dup of #1399
You need to log in before you can comment on or make changes to this bug.