Closing the loop here -- erahm added LAYOUT_WARNING / LAYOUT_WARN_IF_FALSE macros, which are backed by some MOZ_LOG stuff. I posted a PSA about the new macros here: https://groups.google.com/d/msg/mozilla.dev.tech.layout/xsjIrxt9NLM/aEQtVYaRBQAJ
On 06/10/2015 03:48 PM, [email protected] wrote: > On Wednesday, June 10, 2015 at 11:54:36 AM UTC-7, Daniel Holbert wrote: >> On 06/10/2015 02:12 AM, Jet Villegas wrote: >>> I didn't see any arguments against this change. Since this is the #1 >>> ignored warning in the Gecko tree, with thousands of logs per test run, >>> let's silence it except for those actively debugging Layout size bugs. >> >> erahm filed https://bugzilla.mozilla.org/show_bug.cgi?id=1171528 on >> suppressing the #1 warning (about nscoord overflow in a saturating math >> function within nsRect.h). >> >> While reviewing, I realized that this is really a straggling remnant of >> a family of warnings that we removed long ago, in bug 943448; so I >> recommended that he just remove this straggling one as well. >> >> I expect that should be landing soon. >> >> ~Daniel > > Bug 1171528 has landed on inbound. > > It looks like layout/generic/crashtests/421671.html is responsible for almost > all of the other top layout warnings. I wonder if we just want to remove > these as well. > > 42535 - > file:///builds/slave/test/build/tests/reftest/tests/layout/generic/crashtests/421671.html > 2 - No outer window available!: file /dom/base/nsGlobalWindow.cpp, line 3915 > 3 - have unconstrained width; this should only result from very large sizes, > not attempts at intrinsic width calculation: 'NS_UNCONSTRAINEDSIZE != > aAvailSpace.width', file /layout/tables/nsTableRowFrame.cpp, line 50 > 3 - cell content 0x9b9a3190 has large inline size 1073741824 > 3839 - have unconstrained width; this should only result from very large > sizes, not attempts at intrinsic width calculation: 'NS_UNCONSTRAINEDSIZE != > aReflowState.ComputedISize()', file /layout/generic/nsBlockReflowState.cpp, > line 118 > 3848 - have unconstrained inline-size; this should only result from very > large sizes, not attempts at intrinsic inline-size calculation: > 'NS_UNCONSTRAINEDSIZE != computedISizeCBWM && NS_UNCONSTRAINEDSIZE != > availISizeCBWM', file /layout/generic/nsHTMLReflowState.cpp, line 2450 > 3866 - have unconstrained inline-size; this should only result from very > large sizes, not attempts at intrinsic inline-size calculation: > 'AvailableISize() != NS_UNCONSTRAINEDSIZE', file > /layout/generic/nsHTMLReflowState.cpp, line 362 > 3866 - have unconstrained inline-size; this should only result from very > large sizes, not attempts at intrinsic inline-size calculation: '(mFrameType > == NS_CSS_FRAME_TYPE_INLINE && !frame->IsFrameOfType(nsIFrame::eReplaced)) || > type == nsGkAtoms::textFrame || ComputedISize() != NS_UNCONSTRAINEDSIZE', > file /layout/generic/nsHTMLReflowState.cpp, line 454 > 9036 - have unconstrained width; this should only result from very large > sizes, not attempts at intrinsic width calculation: 'psd->mIEnd != > NS_UNCONSTRAINEDSIZE', file /layout/generic/nsLineLayout.cpp, line 884 > 9036 - have unconstrained width; this should only result from very large > sizes, not attempts at intrinsic width calculation: 'psd->mIEnd != > NS_UNCONSTRAINEDSIZE', file /layout/generic/nsLineLayout.cpp, line 3058 > 9036 - have unconstrained width; this should only result from very large > sizes, not attempts at intrinsic width calculation: 'aISize != > NS_UNCONSTRAINEDSIZE', file /layout/generic/nsLineLayout.cpp, line 160 > _______________________________________________ > dev-tech-layout mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-tech-layout > _______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
