Last Comment Bug 230249 - [FIX]Assertion: Negative Width Input - very bad: 'mComputedWidth >= 0'
: [FIX]Assertion: Negative Width Input - very bad: 'mComputedWidth >= 0'
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: All All
: P1 normal (vote)
: mozilla1.7alpha
Assigned To: Boris Zbarsky [:bz] (still a bit busy)
: Jet Villegas (:jet)
Depends on:
  Show dependency treegraph
Reported: 2004-01-06 15:01 PST by Philip K. Warren
Modified: 2004-01-08 09:45 PST (History)
4 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Patch (1.30 KB, patch)
2004-01-07 06:35 PST, Boris Zbarsky [:bz] (still a bit busy)
dbaron: review+
dbaron: superreview+
Details | Diff | Splinter Review

Description Philip K. Warren 2004-01-06 15:01:16 PST
In a debug build from today, I am getting the following assertion several
hundred times while running the editor. It seems to be triggered just from
moving the mouse around the user interface - i.e. move the mouse from the text
input area over all of the buttons on the toolbar and all of the menus.

###!!! ASSERTION: Negative Width Input - very bad: 'mComputedWidth >= 0', file
line 2532
Break: at file
line 2532

I have only tested this on AIX (GTK2 build) for now so I'm not sure if this
affects all platforms or not.

The assertion (not necessarily the code which triggers the assertion) is a
result of the checkin for Bug 227819.
Comment 1 Philip K. Warren 2004-01-06 15:04:12 PST
This assertion is not limited to the Editor - I am also getting it in the Browser.
Comment 2 Boris Zbarsky [:bz] (still a bit busy) 2004-01-06 15:06:27 PST
What are the steps to reproduce for browser?
Comment 3 Philip K. Warren 2004-01-06 15:09:26 PST
Same as for the Editor - it is triggered just by moving the mouse around the 
interface (not clicking anything).
Comment 4 Boris Zbarsky [:bz] (still a bit busy) 2004-01-06 23:19:52 PST
The problem here is that
on the first layout of the adaptor size.width is 0, so availableWidth for the
reflow state is 0.  But the style for the area frame involved has nonzero
margins, so when nsHTMLReflowState::ComputeBlockBoxData does:

          mComputedWidth = availableWidth - mComputedMargin.left -
            mComputedMargin.right - mComputedBorderPadding.left -

we end up with a negative computed width.

I would think that we should use a PR_MAX with 0 here...
Comment 5 Boris Zbarsky [:bz] (still a bit busy) 2004-01-07 06:35:16 PST
Created attachment 138536 [details] [diff] [review]
Comment 6 Boris Zbarsky [:bz] (still a bit busy) 2004-01-07 06:35:58 PST
Comment on attachment 138536 [details] [diff] [review]

David, would you review?
Comment 7 Boris Zbarsky [:bz] (still a bit busy) 2004-01-07 21:22:26 PST
Checked in.
Comment 8 Philip K. Warren 2004-01-08 09:45:45 PST
I am no longer seeing this warning in today's build.

Note You need to log in before you can comment on or make changes to this bug.