Closed Bug 1399 Opened 26 years ago Closed 22 years ago

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

Categories

(Core :: DOM: HTML Parser, defect, P4)

All
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: talmx, Assigned: harishd)

References

Details

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.
Status: NEW → ASSIGNED
Assignee: rickg → karnaze
Status: ASSIGNED → NEW
Chris -- the content model shows that the parser is emitting both input tags. Please look into this.
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
The recent changes to table frame construction may have fixed this.
QA Contact: 4079
Tal, can you check this out and see if its fixed in latest build. Mark the bug VERIFIED if it is..thanks!
Status: RESOLVED → REOPENED
3-10-99 build Not fixt, reopening bug
Resolution: FIXED → ---
QA Contact: 4079 → 3847
stealing qa contact from sujay ;-)
Assignee: karnaze → rickg
Status: REOPENED → NEW
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: rickg → harishd
Sounds like a bad content problem. Assigning the bug to my self and adding rickg and karnaze to the CC list.
Target Milestone: M4
Setting Milestone to M4
Target Milestone: M4 → M5
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.
Status: NEW → RESOLVED
Closed: 26 years ago25 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → REOPENED
Target Milestone: M5 → M6
Resolution: FIXED → ---
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.
Target Milestone: M6 → M7
Moving to M7
Priority: P2 → P3
Target Milestone: M7 → M8
Status: REOPENED → ASSIGNED
Priority: P3 → P4
Target Milestone: M8 → M10
*** Bug 2282 has been marked as a duplicate of this bug. ***
Target Milestone: M10 → M11
Target Milestone: M11 → M14
Target Milestone: M13 → M15
This bug can wait until M15.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → LATER
Sorry guys...got to mark this bug LATER. Fixing this bug would require a lot of work in the sink/parser area.
*** Bug 19116 has been marked as a duplicate of this bug. ***
This bug should be FIXED now.
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?
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
Closed: 25 years ago22 years ago
Resolution: --- → FIXED
Changing QA Contact for verification.
QA Contact: janc → moied
VERIFIED in 2003012508
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.