Closed Bug 4093 Opened 25 years ago Closed 25 years ago

simple table ends up too wide

Categories

(Core :: Layout: Tables, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: kipp, Assigned: karnaze)

Details

(Whiteboard: fixed - justin@debian.org)

Attachments

(1 file)

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: karnaze → kipp
Kipp, I think this is the bug you asked me to reassign to you.
Assignee: kipp → karnaze
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.
Status: NEW → ASSIGNED
chrisd, is this Linux specific?
Target Milestone: M6
Moving to M6.
Moving to M8.
Whiteboard: is this FIXED?
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.
Whiteboard: is this FIXED? → fixed - justin@debian.org
this renders exactly the same in mozilla as it does with communicator 4.6 (m7,
linux). justin@debian.org, july 1
Moving to M9.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
I remember fixing this a long time ago.
Status: RESOLVED → VERIFIED
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.