Form elements in tables but outside <TD></TD> are ignored

VERIFIED FIXED in M15

Status

()

P4
normal
VERIFIED FIXED
20 years ago
16 years ago

People

(Reporter: talmx, Assigned: harishd)

Tracking

Trunk
All
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

20 years ago
In the following HTML the parser does not recognize the "name" INPUT element:
<HTML><BODY>
<FORM ACTION="http://somewhere/somecgi">
<TABLE>
<INPUT name="name" value="value">
<TR><TD>Some data</TD></TR>
</TABLE>
<INPUT type="submit" value="Submit">
</FORM>
</BODY></HTML>

Navigator 4.x seems to handle this by sending the "name" input element. The new
parser, however, ignores the "name" element since CanOmit(eHTMLTag_table,
eHTMLTag_input) returns TRUE.

Updated

20 years ago
Status: NEW → ASSIGNED

Updated

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

Comment 1

20 years ago
Chris -- the content model shows that the parser is emitting both input tags.
Please look into this.

Updated

20 years ago
Status: NEW → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → FIXED

Comment 2

20 years ago
The recent changes to table frame construction may have fixed this.

Updated

20 years ago
QA Contact: 4079

Comment 3

20 years ago
Tal, can you check this out and see if its fixed in latest build.
Mark the bug VERIFIED if it is..thanks!

Updated

20 years ago
Status: RESOLVED → REOPENED

Comment 4

20 years ago
3-10-99 build
Not fixt, reopening bug

Updated

20 years ago
Resolution: FIXED → ---

Updated

20 years ago
QA Contact: 4079 → 3847

Comment 5

20 years ago
stealing qa contact from sujay ;-)

Updated

20 years ago
Assignee: karnaze → rickg
Status: REOPENED → NEW

Comment 6

20 years ago
Nav 4.5 handles this by placing the <INPUT name="name" value="value"> outside
the table. To get this kind of compatibility, the parser will have to do the
same thing. The way the new table frame construction code mighht handle this (if
not for an apparant bug) would be to wrap this <INPUT> in a cell, a row, a row
group and put the row group in the table. However, this would not be compatible
with Nav4.5. Rick, what should be done?
(Assignee)

Updated

20 years ago
Assignee: rickg → harishd
(Assignee)

Comment 7

20 years ago
Sounds like a bad content problem.  Assigning the bug to my self and adding
rickg and karnaze to the CC list.
(Assignee)

Updated

20 years ago
Target Milestone: M4
(Assignee)

Comment 8

20 years ago
Setting Milestone to M4
(Assignee)

Updated

20 years ago
Target Milestone: M4 → M5
(Assignee)

Comment 9

20 years ago
Have a fix for handling illegal contents in table. However, I got to do a lot
more testing that would not be possible within the M4 time frame.  So, moving
the milestone to M5.
(Assignee)

Updated

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

Comment 10

20 years ago
Checked in fix to handle illegal-contents within tables.

Watch for the <INPUT name="name" value="value"> being placed outside the table.

Marking the bug fixed.
(Assignee)

Updated

20 years ago
Status: RESOLVED → REOPENED
Target Milestone: M5 → M6
(Assignee)

Updated

20 years ago
Resolution: FIXED → ---
(Assignee)

Comment 11

20 years ago
Ok...I got to reopen this bug?

Reason: I'm allowing <INPUT> elements to be contained anywhere inside a table.
In other words the <INPUT name="name" value="value"> element is not treated as
an illegal-content and therefore is not getting pulled out of the table.

Setting M6 milestone.
(Assignee)

Updated

20 years ago
Target Milestone: M6 → M7
(Assignee)

Comment 12

20 years ago
Moving to M7
(Assignee)

Updated

20 years ago
Priority: P2 → P3
Target Milestone: M7 → M8
(Assignee)

Updated

20 years ago
Status: REOPENED → ASSIGNED
Priority: P3 → P4
(Assignee)

Updated

20 years ago
Target Milestone: M8 → M10
(Assignee)

Comment 13

19 years ago
*** Bug 2282 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

19 years ago
Target Milestone: M10 → M11
(Assignee)

Updated

19 years ago
Target Milestone: M11 → M14
(Assignee)

Updated

19 years ago
Target Milestone: M13 → M15
(Assignee)

Comment 14

19 years ago
This bug can wait until M15.
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago19 years ago
Resolution: --- → LATER
(Assignee)

Comment 15

19 years ago
Sorry guys...got to mark this bug LATER. Fixing this bug would require a lot of
work in the sink/parser area.
(Assignee)

Comment 16

19 years ago
*** Bug 19116 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 17

19 years ago
This bug should be FIXED now.

Comment 18

19 years ago
This does seem fixed but bug 19116 (a dup of this bug) is *not* fixed yet,
should I unmark that bug as a dup of this bug?

Comment 19

19 years ago
verified

(I agree with jst; marking this bug verified and removing dup from 19166)
Status: RESOLVED → VERIFIED
LATER is deprecated per bug 35839.
Status: VERIFIED → REOPENED
Resolution: LATER → ---
Fixed per above comments.
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago17 years ago
Resolution: --- → FIXED

Comment 22

17 years ago
Changing QA Contact for verification.
QA Contact: janc → moied

Comment 23

16 years ago
VERIFIED in 2003012508
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.