if you look at the reflow log of a simple xul window: <window xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" xmlns:html="http://www.w3.org/1999/xhtml" orient="vertical" style="width: 300px"> </window> you will see that it reflows its children tree times with an initial reflow. This is IHMO wrong and the intial reflow is the most expensive reflow (like style change) it forbids any reflow optimization. One would expect a initial reflow and then a resize reflow. But these two unconstrained initial reflows are too much. VP 0249B480 r=0 a=7344,3456 c=7344,3456 cnt=849 root 0249B588 r=0 a=7344,3456 c=7344,3456 cnt=850 place 0249BE84 r=0 a=UC,UC c=UC,UC cnt=851 place 0249BE84 d=0,0 place 0249BE84 r=0 a=UC,UC c=UC,UC cnt=852 place 0249BE84 d=0,0 place 0249BE84 r=0 a=UC,UC c=UC,UC cnt=853 place 0249BE84 d=0,0 area 0249BDCC r=0 a=UC,UC c=UC,UC cnt=854 area 0249BDCC d=0,0 area 0249BDCC r=0 a=UC,UC c=UC,UC cnt=855 area 0249BDCC d=0,0 area 0249BDCC r=0 a=0,UC c=0,0 cnt=856 area 0249BDCC d=0,0 place 0249BE84 r=0 a=7344,UC c=7344,0 cnt=857 place 0249BE84 d=0,0 root 0249B588 d=7344,3456 VP 0249B480 d=7344,3456 I believe this happens at the RefreshSizeCache function http://lxr.mozilla.org/seamonkey/source/layout/xul/base/src/nsBoxToBlockAdaptor.cpp#299 The function itself is not a problem but the callers: nsBoxToBlockAdaptor::GetPrefSize nsBoxToBlockAdaptor::GetMinSize nsBoxToBlockAdaptor::GetAscent If we now look at nsSprocketLayout::Layout we see it first call GetAscent and later the GetPrefSize and GetMinSize and there are the two bogus reflows

the mew comment at http://lxr.mozilla.org/seamonkey/source/layout/xul/base/src/nsBoxToBlockAdaptor.cpp#311 is completely wrong for normal frames, it might be with xul frames but html frames can show on every reflow the MEW.

the code changed to http://lxr.mozilla.org/seamonkey/source/layout/generic/nsFrame.cpp#4737