Closed
Bug 4093
Opened 25 years ago
Closed 25 years ago
simple table ends up too wide
Categories
(Core :: Layout: Tables, defect, P3)
Tracking
()
VERIFIED
FIXED
M9
People
(Reporter: kipp, Assigned: karnaze)
Details
(Whiteboard: fixed - justin@debian.org)
Attachments
(1 file)
879 bytes,
text/html
|
Details |
A simple table that contains a fixed-width floating table ends up too wide because the floating table reports back a width that is larger than the specified width. However, by the time second pass reflow is done the floating tables width is correct. Here is the sample content (note: the actual images don't matter; use your own...) <html> <body> <table width=100% border=2> <tr><td> Y <table cellspacing=0 cellpadding=0 width=224 border=0 align=right> <tr> <td rowspan=4 width=10><img src="bluedot.gif" width=10 height=1></td> <td width=214><img src="woofer.gif" width=214 height=163 border=0 alt="screen shot"></td> </tr> <tr> <td height=8><img src="bluedot.gif" width=1 height=8 alt=""></td> </tr> <tr> <td><font size=-2 face="MS Sans Serif, Helvetica" color="#666600">CleanSweep Deluxe tracks the files you use most often, then recommends rarely used ones for you to delete.<br></font></td> </tr> <tr> <td height=8><img src="bluedot.gif" width=1 height=8 alt=""></td> </tr> </table> <p>X</td></tr></table> </body> </html>
Assignee | ||
Updated•25 years ago
|
Assignee: karnaze → kipp
Assignee | ||
Comment 1•25 years ago
|
||
Kipp, I think this is the bug you asked me to reassign to you.
Chris: I have more data for you on this bug, and I'm going to bounce it back to you (sigh). I've determined the source of the trouble. In particular, if a table contains a floating table then during pass1 reflow the inner floating table returns a max-element-size that assumes its width is unconstrained EVEN WHEN IT HAS A WIDTH=xxx parameter. Because it returns a large size, the result is that the outer table ends up too wide. What I did to prove this is to instrument the block code and have it log the max-element-size information that it combines to produce its returned value. And then I changed the simpel test in the bug report so that the text in the CENTER tag is longer. And low and behold the inner floating table reported a larger max-element-size than before.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Updated•25 years ago
|
Target Milestone: M6
Assignee | ||
Comment 4•25 years ago
|
||
Moving to M6.
Assignee | ||
Comment 5•25 years ago
|
||
Moving to M8.
Comment 6•25 years ago
|
||
Updated•25 years ago
|
Whiteboard: is this FIXED?
Comment 7•25 years ago
|
||
I recall the above test case behaving as described above. However, a few weeks ago, I noticed that the 'over-width' behaviour was gone. Checking again with a jun23 build win95, this lays out fine. So, is this FIXED|WORKSFORME, or am I missing something in kipp's description.
this renders exactly the same in mozilla as it does with communicator 4.6 (m7, linux). justin@debian.org, july 1
Assignee | ||
Comment 9•25 years ago
|
||
Moving to M9.
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 10•25 years ago
|
||
I remember fixing this a long time ago.
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 11•25 years ago
|
||
Using 8/5 Apprunner on Linux, verified bug fixed.
You need to log in
before you can comment on or make changes to this bug.
Description
•