Steve thinks the problem is because the page has floating tables
The problem seems to be an incremental reflow picking up after a br-clear operation...
Setting all current Open/Normal to M4.
per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
Seems to (lately) be a table layout bug. I've reduced one problem (the left column of the page) to this simple test case. If you remove the second table cell that has a rowspan=5 then the table lays out nicely; otherwise the second image is chopped. <HTML> <HEAD> <base href=http://www.cnnsi.com/> </HEAD> <BODY ZBACKGROUND="http://cnnsi.com/images/backgrounds/blue.line.gif" BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#000099" ALINK="#FFFFFF" VLINK="#7777CC" TOPMARGIN=0> <TABLE CELLPADDING=0 CELLSPACING=0 ALIGN=LEFT WIDTH=142 BORDER=2> <TR><TD COLSPAN=2 VALIGN=TOP> <IMG SRC="/images/navbars/main_us_new.gif" WIDTH=122 HEIGHT=271 BORDER=0 USEMAP="#main_nav"> <IMG SRC="/images/navbars/nav_partner_logos3.gif" USEMAP="#clients" WIDTH="119" HEIGHT="72" BORDER="0"> <BR> </TD><TD ROWSPAN=5 WIDTH=20> </TD></TR> </TABLE> </BODY> </HTML>
a while back troy made some changes to GetEffectiveRowSpan. I wonder if this change caused this problem? It's easy to test, I believe Troy left the commented code in-place. Just swap implementations and retest.
Moving to M8
The page and Kipp's test are ok now. There have been numerous table checkins and I'm not sure which might have fixed it.
The layout of the page is fine in the June 2nd Build.