81268 - Investigate possible issues with recursive reflows

Status: RESOLVED INCOMPLETE

(Core :: Layout, defect, P3)

Description

[Marc Attinasi]

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

Comment 1

[:deanis74]

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

Comment 2

[Marc Attinasi]

Moving Mozilla 1.01 bugs to 'future' milestone with priority P1

I will be pulling bugs from 'future' milestones when scheduling later work.

Comment 3

[Markus Hübner]

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

Comment 4

[Markus Hübner]

Can someone help, as mentioned in comment #3 ?

Comment 5

[Markus Hübner]

Reassigning to [e-mail] for now until someone is willing to take it.

Comment 6

[Mats Palmgren (inactive)]

nsFrame::WillReflow no longer exists.