Re: Proposal: use MOZ_LOG instead of NS_WARNING for spammy warnings about huge nscoord values

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
>