Closed
Bug 6517
Opened 26 years ago
Closed 25 years ago
not seeting max-element-size for certain iframes
Categories
(Core :: Layout, defect, P3)
Tracking
()
VERIFIED
FIXED
M15
People
(Reporter: sspitzer, Assigned: eric)
Details
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
Reporter | ||
Comment 1•26 years ago
|
||
I should add: this is on the 5.14.99 linux build. it is 100% reproducable.
Comment 2•26 years ago
|
||
Might have to do with boxes. Adding Eric Vaughan to cc list.
Updated•26 years ago
|
Target Milestone: M15
Comment 3•26 years ago
|
||
Accepting as a bug for Kipp's list.
Assignee | ||
Updated•26 years ago
|
Assignee: kipp → evaughan
Assignee | ||
Comment 4•26 years ago
|
||
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.
Comment 5•26 years ago
|
||
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;
}
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 6•25 years ago
|
||
fixed
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•