We probably should: (1) relax the MOZ_ASSERT to be a NS_ASSERTION (because fuzzers can trip it via huge sizes and/or sizes that accidentally match sentinel values). We'd still like to be able to notice if it fires for regular content, but it's not strictly enforceable. (2) Depending on why we're failing here and how badly things proceed from this point, we should consider adding a MOZ_UNLIKELY-guarded check to clean up slightly. e.g. if `aNewMinSize` is ending up huge, then we might consider setting `aNewMinSize` to equal `mMainMaxSize` in this case where it's exceeded it. Alternately, if `mMainMaxSize` is the bogus value (e.g. if it's hugely negative), then this would probably be the wrong spot to correct for that; and hopefully that's not something we have to correct for, and we can proceed and just end up with broken layout...
Bug 1730570 Comment 6 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
We probably should: (1) relax the MOZ_ASSERT to be a NS_ASSERTION (because fuzzers can trip it via huge sizes and/or sizes that accidentally match sentinel values). We'd still like to be able to notice if it fires for regular content, but it's not strictly enforceable and we don't want it to crash debug builds. (2) Depending on why we're failing here and how badly things proceed from this point, we should consider adding a MOZ_UNLIKELY-guarded check to clean up slightly. e.g. if `aNewMinSize` is ending up huge, then we might consider setting `aNewMinSize` to equal `mMainMaxSize` in this case where it's exceeded it. Alternately, if `mMainMaxSize` is the bogus value (e.g. if it's hugely negative), then this would probably be the wrong spot to correct for that; and hopefully that's not something we have to correct for, and we can proceed and just end up with broken layout...