when I start up apprunner on the default page (http://www.mozilla.org/quality/smoketests/) I get the following debugging messages from kipp's code in nsContainerFrame.cpp nsContainerFrame: FrameInner(iframe)(1)@0x82985f8 didn't set max-element-size! nsContainerFrame: FrameInner(iframe)(2)@0x82e85f0 didn't set max-element-size! nsContainerFrame: FrameInner(iframe)(4)@0x82c15f8 didn't set max-element-size! kipp's CVS comment for this printf code was: "added some nasty logging messages for frames that don't set max-element-size" on resize of apprunner, I also get these messages. I also get the messages when I drag to make the sidebar are bigger. (messenger also does the same thing on first layout and on subsequent resizes.) Is this a bogus warning, are we doing something wrong in our xul, or is some generated code (tree widget) doing the wrong thing? I'm obviously grasping here, since I have no clue. Anyway, here's a stack trace for when the I get the messages on resize on apprunner with the smoketests startup page: #0 nsContainerFrame::ReflowChild (this=0x82661a8, aKidFrame=0x82985f8, aPresContext=@0x810beb8, aDesiredSize=@0xbfffcb10, aReflowState=@0xbfffca74, aStatus=@0xbfffd0e4) at nsContainerFrame.cpp:400 #1 0x40c77a3a in nsHTMLFrameOuterFrame::Reflow (this=0x82661a8, aPresContext=@0x810beb8, aDesiredSize=@0xbfffd140, aReflowState=@0xbfffcba0, aStatus=@0xbfffd0e4) at nsFrameFrame.cpp:383 #2 0x40d237c9 in nsBoxFrame::FlowChildAt (this=0x824b7b8, childFrame=0x82661a8, aPresContext=@0x810beb8, desiredSize=@0xbfffd140, aReflowState=@0xbfffcf4c, aStatus=@0xbfffd0e4, spring=1, incrementalChild=@0xbfffcee4) at nsBoxFrame.cpp:661 #3 0x40d228b2 in nsBoxFrame::FlowChildren (this=0x824b7b8, aPresContext=@0x810beb8, aDesiredSize=@0xbfffd140, aReflowState=@0xbfffcf4c, aStatus=@0xbfffd0e4, rect=@0xbfffcee8, incrementalChild=@0xbfffcee4) at nsBoxFrame.cpp:373 #4 0x40d22342 in nsBoxFrame::Reflow (this=0x824b7b8, aPresContext=@0x810beb8, aDesiredSize=@0xbfffd140, aReflowState=@0xbfffcf4c, aStatus=@0xbfffd0e4) at nsBoxFrame.cpp:258 #5 0x40baba70 in nsBlockReflowContext::ReflowBlock (this=0xbfffd104, aFrame=0x824b7b8, aSpace=@0xbfffd0e8, aApplyTopMargin=1, aPrevBottomMargin=0, aIsAdjacentWithTop=1, aComputedOffsets=@0xbfffd0d4, aFrameReflowStatus=@0xbfffd0e4) at nsBlockReflowContext.cpp:227 #6 0x40ba56f8 in nsBlockFrame::ReflowBlockFrame (this=0x82490e0, aState=@0xbfffd218, aLine=0x82822f0, aKeepReflowGoing=0xbfffd1e4) at nsBlockFrame.cpp:2493 #7 0x40ba46c2 in nsBlockFrame::ReflowLine (this=0x82490e0, aState=@0xbfffd218, aLine=0x82822f0, aKeepReflowGoing=0xbfffd1e4) at nsBlockFrame.cpp:1983 #8 0x40ba4115 in nsBlockFrame::ReflowDirtyLines (this=0x82490e0, aState=@0xbfffd218) at nsBlockFrame.cpp:1793 #9 0x40ba3451 in nsBlockFrame::Reflow (this=0x82490e0, aPresContext=@0x810beb8, aMetrics=@0xbffff3b0, aReflowState=@0xbffff314, aStatus=@0xbffff660) at nsBlockFrame.cpp:1199 #10 0x40ba0dcc in nsAreaFrame::Reflow (this=0x82490e0, aPresContext=@0x810beb8, aDesiredSize=@0xbffff3b0, aReflowState=@0xbffff314, aStatus=@0xbffff660) at nsAreaFrame.cpp:265 #11 0x40baf31d in nsContainerFrame::ReflowChild (this=0x8248b48, aKidFrame=0x82490e0, aPresContext=@0x810beb8, aDesiredSize=@0xbffff3b0, aReflowState=@0xbffff314, aStatus=@0xbffff660) at nsContainerFrame.cpp:392 #12 0x40bba9b3 in RootFrame::Reflow (this=0x8248b48, aPresContext=@0x810beb8, aDesiredSize=@0xbffff514, aReflowState=@0xbffff470, aStatus=@0xbffff660) at nsHTMLFrame.cpp:223 #13 0x40baf31d in nsContainerFrame::ReflowChild (this=0x8245738, aKidFrame=0x8248b48, aPresContext=@0x810beb8, aDesiredSize=@0xbffff514, aReflowState=@0xbffff470, aStatus=@0xbffff660) at nsContainerFrame.cpp:392 #14 0x40be5615 in ViewportFrame::Reflow (this=0x8245738, aPresContext=@0x810beb8, aDesiredSize=@0xbffff664, aReflowState=@0xbffff5bc, aStatus=@0xbffff660) at nsViewportFrame.cpp:436 #15 0x40bd3b40 in PresShell::ResizeReflow (this=0x81618d8, aWidth=11040, aHeight=8670) at nsPresShell.cpp:937 #16 0x40bd6c57 in PresShell::ResizeReflow (this=0x81618d8, aView=0x815dc80, aWidth=11040, aHeight=8670) at nsPresShell.cpp:2035 #17 0x41091262 in nsViewManager::SetWindowDimensions (this=0x815da80, width=11040, height=8670) at nsViewManager.cpp:355 #18 0x4109435b in nsViewManager::DispatchEvent (this=0x815da80, aEvent=0xbffff7d8, aStatus=@0xbffff77c) at nsViewManager.cpp:1593 #19 0x41089998 in HandleEvent (aEvent=0xbffff7d8) at nsView.cpp:66 #20 0x400c4702 in nsWidget::DispatchEvent (this=0x815dce8, event=0xbffff7d8, aStatus=@0xbffff7b8) at nsWidget.cpp:981 #21 0x400c460c in nsWidget::DispatchWindowEvent (this=0x815dce8, event=0xbffff7d8) at nsWidget.cpp:943 #22 0x400c3759 in nsWidget::OnResize (this=0x815dce8, aRect=@0x8310228) at nsWidget.cpp:346 #23 0x400c1367 in idle_resize_cb (data=0x84587d8) at nsGtkEventHandler.cpp:288 #24 0x4065ddc9 in g_idle_dispatch () #25 0x4065cdd2 in g_main_dispatch () #26 0x4065d3bb in g_main_iterate () #27 0x4065d571 in g_main_run () #28 0x4058415b in gtk_main () #29 0x400b6c31 in nsAppShell::Run (this=0x809aa98) at nsAppShell.cpp:206 #30 0x4001d4f9 in nsAppShellService::Run (this=0x8078490) at nsAppShellService.cpp:391 #31 0x804ba68 in main (argc=1, argv=0xbffffa24) at nsAppRunner.cpp:462

I should add: this is on the 5.14.99 linux build. it is 100% reproducable.

Might have to do with boxes. Adding Eric Vaughan to cc list.

Accepting as a bug for Kipp's list.

Many of our widgets don't set Max element size. I assume the bug is to catch anyone who does not set it. I'll take a look and see if I can fix the places that need it.

Comments from "Roger B. Sidje" <rbs@maths.uq.edu.au>: On M6 Win95, in the course of implementing a frame for MathML, I came to the observation that not setting max-element-size actually causes two reflows!! Possibly more?! That is why the "didn't set max-element-size!" is printed twice for each frame that didn't set the max-element-size. Moreover by adding a brute "printf(something); getchar();" in the paint method of the frame, I noticed that the paint method is called six times!!! This is a bug of its own. It happens irrespective of whether max-element-size is set or not. But there is a curious behavior that happens when max-element-size is not set. In such a case, the paint method is called (again six times) when the mouse goes out of the window. When the max-element-size is set, the paint is called once (still unnecessary). It is a recorded bugzilla bug that those multiple paints are wrong. Do all of the repaints (or only a part of the repaints) have something to do with the max-element-size not set? And why? These questions are in the sphere of the layout gurus! Perhaps that's one of the reasions the UI is still slow? Please try to reproduce on a simple frame and if you also come to the conclusion that not setting the max-element-size causes multiple reflows and repaints, then as a matter of urgency, "frame makers" could revisit their reflow code and set their max-element-size. If I am not much mistaken, this is simply done by ensuring that each completed reflow method ends with something like: ... if (nsnull != aDesiredSize.maxElementSize) { aDesiredSize.maxElementSize->width = aDesiredSize.width; aDesiredSize.maxElementSize->height = aDesiredSize.height; } aStatus = NS_FRAME_COMPLETE; return NS_OK; }

fixed

Fixed in the May 22 nd build.