In the following html, the block containing the nested table is generating an incremental reflow command that has a null chain. The debug output below (starts with the cell containing the nested table) shows that the table code is correctly removing frames from the chain. The last line shows that the nested table is getting a reflow with a null chain which is comming from the block containing the nested table. The debugging output is turned on by the flag in nsTableFrame.cpp and the reflow chain is dumped by uncommenting code in nsTableFrame::DebugReflow (the dumping of the reflow chain will not be checked in for a day or two however). <TABLE WIDTH=375 BGCOLOR=#3834D0 CELLPADDING=0 CELLSPACING=0 BORDER=0> <TR VALIGN=TOP> <TD COLSPAN=2> <TABLE VALIGN=TOP BORDER=0 CELLPADDING=0 CELLSPACING=0 WIDTH=100% ALIGN=LEFT> <FORM> <TR VALIGN=TOP> <TD ALIGN=LEFT> <INPUT TYPE="PASSWORD" SIZE=8 NAME="password"> </TD> </TR> </FORM> </TABLE> </TD> </TR> </TABLE> TC::Rfl 023B44E0 rea=1 av=(5625,UC) comp=(5625,UC) count=30 reflow chain = 023B453C 023B45C0 023B4614 023B46F4 023B4734 023B477C 023B47D8 02 3B86C0 Area::Rfl en 023B453C rea=1 av=(5625,UC) comp=(5625,UC) count=31 reflow chain = 023B45C0 023B4614 023B46F4 023B4734 023B477C 023B47D8 023B86C0 TO::Rfl en 023B45C0 rea=1 av=(5625,UC) comp=(5625,UC) count=32 reflow chain = 023B4614 023B46F4 023B4734 023B477C 023B47D8 023B86C0 state= 0012BD94 reflowCommand=02272790 T::Rfl en 023B4614 rea=1 av=(5625,UC) comp=(5625,UC) count=33 reflow chain = 023B46F4 023B4734 023B477C 023B47D8 023B86C0 TRG::Rfl 023B46F4 rea=1 av=(5625,UC) comp=(5625,UC) count=34 reflow chain = 023B4734 023B477C 023B47D8 023B86C0 TR::Rfl en 023B4734 rea=1 av=(5625,UC) comp=(5625,UC) count=35 reflow chain = 023B477C 023B47D8 023B86C0 TC::Rfl 023B477C rea=1 av=(5625,UC) comp=(5625,UC) count=36 reflow chain = 023B47D8 023B86C0 Area::Rfl en 023B47D8 rea=1 av=(5625,UC) comp=(5625,UC) co unt=37 reflow chain = 023B86C0 Area::Rfl ex 023B47D8 des=(5625,405) maxElem=(1365,405) TC::Rfl ex 023B477C des=(5625,405) maxElem=(1365,405) TR::Rfl ex 023B4734 des=(5625,405) maxElem=(1365,405) TRG::Rfl ex 023B46F4 des=(5625,0) maxElem=(1365,405) TRG::Rfl 023B46F4 rea=2 av=(5625,UC) comp=(5625,UC) count=38 TR::Rfl en 023B4734 rea=2 av=(5625,UC) comp=(5625,UC) count=39 TR::Rfl ex 023B4734 des=(5625,405) TRG::Rfl ex 023B46F4 des=(5625,405) T::Rfl ex 023B4614 des=(5625,405) maxElem=(1365,0) TO::Rfl ex 023B45C0 des=(5625,405) maxElem=(1365,0) TO::Rfl en 023B45C0 rea=1 av=(5625,UC) comp=(5625,UC) count=40 reflow chain =

you've obviously forgotten that block code is perfect in every way. you must be confused. on the off chance that you're actually right, how important is this? what grief does it cause you?

It was causing a lot of grief on aol.com and other pages, until I changed table code to expect it (not checked in yet). Troy suspects the reflow coalescing. This problem has only surfaced within the last 1 to 3 weeks. Maybe Nisheeth should take a look at it.

based on Karnaze's comments, assigning to Nisheeth, priority P2, severity major. I'd hate for chris to have to check in some evil hack, and the AOL website is pretty important to get right. Nisheeth, if this is not yours, throw it back into Kipp's pile. chris: what is the impact of this bug? Is the layout on the page wrong? Are there assertions? If so, do they actually effect layout or behavior, or are they "just" warnings?

nsOuterTableFrame is returning a desired height of 0 when this happens and content is lost. I am changing it to return mRect.height instead which isn't a bad thing and works around the problem.

Accepting bug and setting target milestone to M14...

Here's what seems to be happening: The following code in nsBlockFrame::ReflowLine() gets executed: // First reflow the line with an unconstrained width ReflowInlineFrames(aState, aLine, aKeepReflowGoing, PR_TRUE); // Update the line's maximum width aLine->mMaximumWidth = aLine->mBounds.XMost(); aState.UpdateMaximumWidth(aLine->mMaximumWidth); // Remove any floaters associated with the line from the space // manager aLine->RemoveFloatersFromSpaceManager(aState.mSpaceManager); // Now reflow the line again this time without having it compute // the maximum width aState.mY = oldY; aState.mPrevBottomMargin = oldPrevBottomMargin; rv = ReflowInlineFrames(aState, aLine, aKeepReflowGoing); The placeholder frame for the floated table is reflowed in both the calls to ReflowInlineFrames(). The reflow chain gets emptied during the first call to ReflowInlineFrames(). When the second call to ReflowInlineFrames() is made, the outer table frame of the floated table ends up getting a reflow command with a null reflow chain. I don't know enough about block code to say how we should fix it. Troy?

I re-assigned it to me, and I'll take a look. Buster, this is a good example of what's wrong with the floater code. The way it currently works whenever it stumbles across the placeholder frame it decides to reflow it. Yuck.

Fixed block code to set mNextRCFrame to NULL after reflowing the frame. This way if we reflow it again we don't think it's still an incremental reflow

Marking verified based on last comments.