Closed
Bug 38916
Opened 25 years ago
Closed 25 years ago
problems with <IFRAME>
Categories
(Core :: Layout: Tables, defect, P3)
Tracking
()
VERIFIED
FIXED
Future
People
(Reporter: Henric.Boehm, Assigned: karnaze)
Details
(Keywords: testcase, Whiteboard: testcase)
Attachments
(2 files)
The frame content is placed different to the frame border.
The content is above the border. The border ist displayed correctly and at the
right position.
Source code:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD>
<TITLE>Menu</TITLE>
<LINK REL="stylesheet" TYPE="text/css" href="Index.css">
<STYLE TYPE="text/css"></STYLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<SCRIPT src="master.js" type="text/javascript1.2"></SCRIPT>
</HEAD>
<BODY>
<TABLE border="0" cellPadding="1" cellSpacing="0" RULES="ROWS">
<THEAD>
<TR>
<TD align="left">
<H1><A HREF="HKA_I0.html" TARGET="_top">title</H1>
</TD>
<TFOOT>
<TR>
<TD align="left">
<B><A HREF="LO_R1.html" TITLE="LogOn" TARGET="main">* Testumgebung *</A></B>
<UL>
<LI><A HREF="LO_R0.html" TARGET="_top">LogOff</A>
</UL>
</TD>
<TR>
<TD align="center">
<IFRAME name="Status" SRC="about:blank" HEIGHT="150" WIDTH="125"
scrolling="NO">
</IFRAME>
</TD>
<TBODY>
<TR>
<TD align=left>
<B>Unternehmen</B>
<UL>
<LI><A HREF="UN_ERF1.html" TARGET="main">Erfassen</A>
<LI><A HREF="UN_AUS0.html" TARGET="main">Suchen</A>
</UL>
</TD>
<TR>
<TD align=left>
<B>Ansprechpartner</B>
<UL>
<LI><A HREF="AA_BAN1.html" TARGET="main">Beantragen</A>
<LI><A HREF="AA_AUS1.html" TARGET="main">Suchen</A>
</UL>
</TD>
</TABLE>
</BODY>
</HTML>
Reporter | ||
Comment 1•25 years ago
|
||
occures, when the <IFRAME>-tag is placed in the <TFOOT>-area of a table
Comment 2•25 years ago
|
||
confirming b: 2000-05-11-08 win32,
although these thead, tbody etc. are IE specific and this document doesn´t
validate as HTML 4.0 (attribute cases, one time missing </A>) mozilla should
render it normally, only <TFOOT> seems to produce this effect
- if you try closing TFOOT, with </TFOOT> directly behind it renders normally
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•25 years ago
|
||
Comment 4•25 years ago
|
||
Despite what André said above, THEAD and TFOOT are in fact part of HTML4
and do work in mozilla, but not quite in this case. The attached testcase
is a simplified form of the problem; it just appears that if an iframe is
inside a TFOOT or TBODY, the dimensions of the IFRAME (or some underlying
structure) are miscalculated, and it's contents overlap the TBODY (or TFOOT).
Assignee: clayton → karnaze
Component: HTML Element → HTMLTables
QA Contact: petersen → chrisd
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 5•25 years ago
|
||
The problem appears to be with placing the <IFRAME> inside the <TFOOT>. When I
changed the <TFOOT> to <TBODY> it looked ok.
Assignee | ||
Comment 6•25 years ago
|
||
This bug has been marked "future" because the original netscape engineer working
on this is over-burdened. If you feel this is an error, that you or another
known resource will be working on this bug,or if it blocks your work in some way
-- please attach your concern to the bug for reconsideration.
Target Milestone: --- → Future
Comment 7•25 years ago
|
||
Adding testcase keyword so this doesn't show up on the bugathon search page.
Keywords: testcase
Whiteboard: testcase
Comment 8•25 years ago
|
||
Comment 9•25 years ago
|
||
Chris: I appreciate the workload that you are under, and the need to make
difficult cuts in features. However, I do think this one should get
reconsideration. Perhaps this isn't too difficult to fix, as well: the table
knows the correct position and width/height for the child iframe (note that
CSS applied to the IFRAME is in the correct position); it's just that the child
document (iframe) itself is offset vertically from this correct position.
Anyways, just my two cents.
Assignee | ||
Comment 10•25 years ago
|
||
This is now fixed and was considered during the fix for 30418.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•