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 /home/pkw/sb/mozilla/trunk/mozilla/layout/html/base/src/nsHTMLReflowState.cpp, line 2532 Break: at file /home/pkw/sb/mozilla/trunk/mozilla/layout/html/base/src/nsHTMLReflowState.cpp, 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.
This assertion is not limited to the Editor - I am also getting it in the Browser.
What are the steps to reproduce for browser?
Same as for the Editor - it is triggered just by moving the mouse around the interface (not clicking anything).
The problem here is that athttp://lxr.mozilla.org/seamonkey/source/layout/xul/base/src/nsBoxToBlockAdaptor.cpp#802 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 - mComputedBorderPadding.right; we end up with a negative computed width. I would think that we should use a PR_MAX with 0 here...
13 years ago
Comment on attachment 138536 [details] [diff] [review] Patch David, would you review?
I am no longer seeing this warning in today's build.