Closed
Bug 1611
Opened 26 years ago
Closed 26 years ago
Pages laying out _wide_
Categories
(Core :: Layout, defect, P2)
Tracking
()
VERIFIED
FIXED
People
(Reporter: joe, Assigned: buster)
References
()
Details
It seems that certain pages - for example, Slashdot - are laying out very wide,
though the content itself is within the confines of the regular browser window.
There is, however, a horizontal scrollbar you can use to see the nothing that's
on the other bits of the page.
While it doesn't hurt on Slashdot, MaximumPC.com is much worse - it actually
lays out so that the page is as wide as the scrollbar.
(This is relative to the win32 build from ftp.mozilla.org on Nov 24)
Assignee: buster → kipp
Status: ASSIGNED → NEW
this looks like a body or block incremental reflow bug, not a table bug.
During incremental reflow, the cell's body frame is reflowed 3 times:
1. incremental reflow is passed down
2. pass-1 reflow is done
3. pass-2 reflow is done
During step 2 (pass-1 reflow after an incremental reflow) the body psuedo-frame
returns back a very large max element size to the parent cell, making the whole
page too wide.
Remove the image from the test case, and the tables lay out correctly.
============= test case ===================
<HTML><BODY>
<TABLE BORDER="0" CELLSPACING="0" CELLPADDING="0" WIDTH="100%" >
<TR>
<TD BGCOLOR="#FFFFFF">
<TABLE BORDER="0" CELLSPACING="20" CELLPADDING="5">
<TR>
<TD>
<IMG SRC="http://www.maximumpc.com/gfx/news.gif"
ALT="News" width=100>
A Computer For Your Car | 12.03.98 12:33
Still looking for that perfect holiday gift for
that special PC fanatic in your life? If so, you might want to consider the Auto
PC, an in-dash personal assistant combining a car stereo with the functionality
of a personal computer.
<BR CLEAR="ALL"><HR WIDTH="60%">
</TD>
<TD WIDTH="150" BGCOLOR="#E3C300">xxx</TD>
</TR>
</TABLE>
</TD>
</TR>
</TABLE>
</body></html>
Here's what's going on:
The page initially loads correctly. You can see this if you watch carefully:
the page paints with all the elements in the
right place then immediately horks itself.
The horkage is caused by the incremental reflow triggered by the image load.
Remove the image so no incremental
reflow is triggered, the page looks great.
The incremental reflow is targeted at the cell content. So the row containing
the cell goes through these steps (see
nsTableRowFrame::IR_TargetIsChild around line 1250):
1. pass down the incremental reflow
2. pass down a resize reflow with unconstrained size and a non-null max element
size. This is required in case the result
of the incremental reflow changed the cell content's desired size or max element
size.
3. pass down a resize reflow with the new constrained width (optimistically
hoping the column width hasn't changed)
The maxElementSize returned by the cell content in step 2 is different than the
maxElementSize returned during initial
unconstrained reflow. I first thought this might be because the reflow state's
"widthConstraint" wasn't getting set when it's
maxSize.width was getting set, but I changed that and it made no difference
(I'll check it in anyway, because it's the right
thing to do for now, the real right thing to do is add an interface that changes
the width and the flag simultaneously so the
caller doesn't have to worry about it! Troy, you want to add that?)
So back to you, Kipp. The big width being passed back down to the cell content
is just the maxElementSize the content
had previously reported during resize reflow with an unconstrained width. Why
would the same content give 2 different
maxElementSize results? Are you triggering something off of the reflow reason,
assuming unconstrained reflow can only
happen during initial reflow or something like that?
You need to log in
before you can comment on or make changes to this bug.
Description
•