simple table ends up too wide

VERIFIED FIXED in M9

Status

()

Core
Layout: Tables
P3
normal
VERIFIED FIXED
19 years ago
19 years ago

People

(Reporter: kipp, Assigned: karnaze (gone))

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fixed - justin@debian.org)

Attachments

(1 attachment)

(Reporter)

Description

19 years ago
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

19 years ago
Assignee: karnaze → kipp
(Assignee)

Comment 1

19 years ago
Kipp, I think this is the bug you asked me to reassign to you.
(Reporter)

Updated

19 years ago
Assignee: kipp → karnaze
(Reporter)

Comment 2

19 years ago
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

19 years ago
Status: NEW → ASSIGNED

Comment 3

19 years ago
chrisd, is this Linux specific?
(Assignee)

Updated

19 years ago
Target Milestone: M6
(Assignee)

Comment 4

19 years ago
Moving to M6.
(Assignee)

Comment 5

19 years ago
Moving to M8.

Comment 6

19 years ago
Created attachment 556 [details]
just posting kipp's testcase from above

Updated

19 years ago
Whiteboard: is this FIXED?

Comment 7

19 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.

Updated

19 years ago
Whiteboard: is this FIXED? → fixed - justin@debian.org

Comment 8

19 years ago
this renders exactly the same in mozilla as it does with communicator 4.6 (m7,
linux). justin@debian.org, july 1
(Assignee)

Comment 9

19 years ago
Moving to M9.
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 10

19 years ago
I remember fixing this a long time ago.

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 11

19 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.