Closed
Bug 398157
Opened 17 years ago
Closed 17 years ago
"ASSERTION: didn't subtract all that we added" with <select>, <div style="margin: 0 100%;">
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: jruderman, Assigned: dholbert)
References
Details
(Keywords: assertion, testcase)
Attachments
(2 files)
131 bytes,
application/xhtml+xml
|
Details | |
1.02 KB,
patch
|
roc
:
review+
roc
:
superreview+
roc
:
approval1.9+
|
Details | Diff | Splinter Review |
This testcase triggers a bunch of assertions, including one I haven't seen elsewhere recently:
###!!! ASSERTION: didn't subtract all that we added: 'space == 0 && ((l2t == FLEX_PCT_LARGE) ? (-0.001f < basis.f && basis.f < 0.001f) : (basis.c == 0 || basis.c == nscoord_MAX))', file /Users/jruderman/trunk/mozilla/layout/tables/BasicTableLayoutStrategy.cpp, line 1013
Note that this isn't the same assertion as in bug 398043. That one is in BasicTableLayoutStrategy::ComputeColumnIntrinsicWidths; this one is in BasicTableLayoutStrategy::ComputeColumnWidths.
Assignee | ||
Comment 1•17 years ago
|
||
Trivial fix.
Issue arises when "width" is nscoord_MAX in ComputeColumnWidths. We'd been subtracting directly off of "width", and we need to use NSCoordSaturatingSubtract instead.
Assignee: nobody → dholbert
Status: NEW → ASSIGNED
Attachment #283036 -
Flags: superreview?
Attachment #283036 -
Flags: review?
Attachment #283036 -
Flags: approval1.9?
Assignee | ||
Updated•17 years ago
|
Attachment #283036 -
Flags: superreview?(roc)
Attachment #283036 -
Flags: superreview?
Attachment #283036 -
Flags: review?(roc)
Attachment #283036 -
Flags: review?
Assignee | ||
Updated•17 years ago
|
OS: Mac OS X → All
Attachment #283036 -
Flags: superreview?(roc)
Attachment #283036 -
Flags: superreview+
Attachment #283036 -
Flags: review?(roc)
Attachment #283036 -
Flags: review+
Attachment #283036 -
Flags: approval1.9?
Attachment #283036 -
Flags: approval1.9+
Assignee | ||
Comment 2•17 years ago
|
||
Fix checked in.
Checking in BasicTableLayoutStrategy.cpp;
/cvsroot/mozilla/layout/tables/BasicTableLayoutStrategy.cpp,v <-- BasicTableLayoutStrategy.cpp
new revision: 3.260; previous revision: 3.259
done
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Comment 3•17 years ago
|
||
This looks okay on Win XP using Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a9pre) Gecko/2007100204 Minefield/3.0a9pre. However, using the same build on mac paralyzes my entire system. On one Intel test machine I had to shut down the machine to get out of the cycle. juanb had the same thing happen to him.
Assignee | ||
Comment 4•17 years ago
|
||
Don't think the hang is caused by this bug's fix... stephend tried this Mac build:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a9pre) Gecko/2007100120 Minefield/3.0a9pre
(after the fix was checked in) and it didn't hang.
Comment 5•17 years ago
|
||
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a9pre) Gecko/2007100204 Minefield/3.0a9pre -> paralyzes my entire system on mac.
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a9pre) Gecko/2007100104 Minefield/3.0a9pre -> is working fine
so this patch caused a regression on mac.
Comment 6•17 years ago
|
||
did some more testings and this seems to be no regression, the hang is also reproducible in 2007100104 and Gran Paradiso Alpha 8 Builds when you use this testcase and click on the "bar" in this testcase.
Filed Bug 398336 for this problem.
You need to log in
before you can comment on or make changes to this bug.
Description
•