While investigating another problem, I put a check in nsFrame::WillReflow to assert if the frame is already in a reflow. Strangely, this assert gets triggered whenever I pop up a XUL-based dialog (preferences dialog in browser, or table dialog in Composers, for example). I cannot understand yet if we support recursive reflows in some cases, all cases, or if this is a bug. The frame in question is always the ViewportFrame. Here is the code I added: NS_IMETHODIMP nsFrame::WillReflow(nsIPresContext* aPresContext) { #ifdef DEBUG if (0 != (mState & NS_FRAME_IN_REFLOW)) { NS_ASSERTION(0 == (mState & NS_FRAME_IN_REFLOW), "frame is already in reflow"); nsresult rv = NS_OK; } #endif NS_FRAME_TRACE_MSG(NS_FRAME_TRACE_CALLS, ("WillReflow: oldState=%x", mState)); mState |= NS_FRAME_IN_REFLOW; return NS_OK; } This bug is a reminder to investigate this...

*** Bug 81269 has been marked as a duplicate of this bug. ***

Moving Mozilla 1.01 bugs to 'future' milestone with priority P1 I will be pulling bugs from 'future' milestones when scheduling later work.

Think this problem has been mentioned elsewhere in the meantime, but cannot remember where ... hm.

Can someone help, as mentioned in comment #3 ?

Reassigning to other@layout.bugs for now until someone is willing to take it.

nsFrame::WillReflow no longer exists.