tripping "Negative Width/Height Result- very bad"

NEW
Unassigned

Status

()

Core
Layout
P3
minor
17 years ago
8 years ago

People

(Reporter: Chris Waterson, Unassigned)

Tracking

({top100})

Trunk
mozilla1.2alpha
top100
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fixed?], URL)

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
To reproduce, need a debug build.

1. Visit http://www.yahoo.com

Actual: Hit ``mComputedHeight>=0, "Negative Height Result- very bad"'' assertion
around line 2444 of nsHTMLReflowState.cpp. mComputedHeight == -15 at this point.

Expected: Assertion should not fire.
(Reporter)

Comment 1

17 years ago
So this appears to be happening on the HR frame (as your XXXcomment notes!) It
looks like the problem is that the HR's mStylePosition->mHeight == 15 (1px), and
it's top and bottom borders are each 1px. So, when we crunch the borders in
around it, we end up with 15 (height according to mStylePosition) less 15 (top
border) less 15 (bottom border), or -15.
Severity: normal → minor
(Reporter)

Comment 2

17 years ago
Created attachment 27029 [details]
minimal test case

Comment 3

17 years ago
Thanks Chris! I'll try to figure out what the deal is with HR frames, but in the 
meantime I think I better comment out the assertion to avoid pissing-off the 
Gods...
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.8.1

Comment 4

17 years ago
Moving off to Moz0.9
Target Milestone: mozilla0.8.1 → mozilla0.9

Comment 5

17 years ago
*** Bug 64632 has been marked as a duplicate of this bug. ***
I'm copying a recent comment from bug 64632 (dup'd to this) because I think
there's some useful info in it (and another testcase).

----
FreeBSD 4.1 20010306xx re-verified bug exists (assertion on display, didn't try
crashing it on print)

Assertions (10 of them for height < 0) can be seen at http://sharkyextreme.com

###!!! ASSERTION: Negative Height Result- very bad: 'mComputedHeight>=0', file
nsHTMLReflowState.cpp, line 2444

(height was -14 again, due to moz-bg-inset).  Note that this page is NOT marked
as standard (though it does use some simple styles).

OS->All
Severity->critical (it's a crasher)
Changed subject

Related issue: on Linux ns4.7, shaded (normal) HR's are all 1 pixel too tall.  I
suspect this code: 

if (!noShadeAttribute) { // this makes us compatible with Nav4, and one pixel
taller than IE5
    thickness += onePixel;

We're one pixel taller than ns4.7 (Linux).  I suspect we're one pixel taller
than ns 4.x and ie5 on all platforms, and that this if should go away.

Again, I suggest that we remove this test:
    // fix up thickness based on noshade and mode.  see bug 53568 and 54980
    if (eCompatibility_NavQuirks == mode)

I think that the border thickness (moz-bg-inset) needs to be compensated for in
all cases.

Comment 7

17 years ago
Getting the assertion for Negative Width running the table regression tests too
- need to figure out why (again, removing the assertion for now).
Summary: tripping "Negative Height Result- very bad" → tripping "Negative Width/Height Result- very bad"

Comment 8

17 years ago
Marc, just look into the testcase for bug 30692. I believe these asserts are
partly the bad outcome of reflow + parent relationship bugs.

Comment 9

17 years ago
Moving out: the assertiosn have been commented out, and the routines that were
asserting already handle the case of negative width and height (by setting to 0)
so the severity is low.
Priority: -- → P3
Target Milestone: mozilla0.9 → mozilla1.0
NOTE: the problem is not just the assertion, and removing the assertion (and
limiting sizes to 0) may not solve all the problems (though it should solve the
crashes).  As per my comments, our shaded HR's are not the same size as on other
browsers, and may be uniformly off.

From having looked at this a few times (like when we had the inside-out noshade
HR's due to this), I think the problem is due to moz-bg-inset subtracting the
border size from an element size that can be 0.  Please verify that HR's are
correctly sized for shade and non-shade values before putting this in the "we
don't care" pile.  Also, don't use Linux ns4.x for testing; use Win32 ns4.x and
IE5/etc.  From my comments I think the Linux version of ns4.x also has a bug
here.

Comment 11

17 years ago
Hey Randell, it is not that I don't care, it is just that I have a load of
crashers and data-loss issues to tackle first. I saw the information that you
posted about the HR, which I really appreciate, and I'd love to play with it,
but I'm swamped by stability issues right now. (Is it moz-bg-inset that is
subtracting the border, or is it the box-sizing? The assert only happens in
Quirks mode, and the box-sizing is set in Quirks mode...)

Updated

16 years ago
Target Milestone: mozilla1.0 → mozilla1.2

Comment 12

14 years ago
This report is pretty old and I can't reproduce this in a debug build on winxp
from this morning (2004-04-06) either in the minimal test case or in any of many
yahoo pages. 

I think this is either a wfm or fixed.
Keywords: top100
Whiteboard: [fixed?]
Assignee: attinasi → nobody
Status: ASSIGNED → NEW
QA Contact: chrispetersen → layout
You need to log in before you can comment on or make changes to this bug.