Closed Bug 510748 Opened 11 years ago Closed 11 years ago

still get assertions "reflow state computed incorrect width" and "non-root frame's desired size changed during an incremental reflow"

Categories

(Core :: Layout: Block and Inline, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.9.3a1
Tracking Status
status1.9.2 --- beta1-fixed

People

(Reporter: tnikkel, Assigned: tnikkel)

References

Details

Attachments

(1 file)

Bug 486065 fixed the phantom scroll bars from showing up and get rid of most of the "reflow state computed incorrect width" and "non-root frame's desired size changed during an incremental reflow" assertions but a few still remain. In gdb I get:

###!!! ASSERTION: reflow state computed incorrect width: 'reflowState.ComputedWidth() == size.width - reflowState.mComputedBorderPadding.LeftRight()', file /src/layout/base/nsPresShell.cpp, line 7169

(gdb) p reflowState.ComputedWidth()
$8 = 0
(gdb) p size.width
$9 = 60
(gdb) p reflowState.mComputedBorderPadding.LeftRight()
$10 = 120

###!!! ASSERTION: non-root frame's desired size changed during an incremental reflow: '(target == rootFrame && size.height == NS_UNCONSTRAINEDSIZE) || (desiredSize.width == size.width && desiredSize.height == size.height)', file /src/layout/base/nsPresShell.cpp, line 7186

(gdb) p desiredSize.width
$11 = 120
(gdb) p size.width
$12 = 60
(gdb) p desiredSize.height
$13 = 0
(gdb) p size.height
$14 = 0

Can we fix this by just setting the border/padding to zero on _both_ axes if either the width or the height is zero? This patch fixes the assertions for me.
Attachment #394695 - Flags: review?(dbaron)
Attachment #394695 - Flags: review?(dbaron) → review+
Comment on attachment 394695 [details] [diff] [review]
patch?
[Checkin: Comment 5]

r=dbaron

Are you getting those assertions on a test that's already in our test suites, or do we need to add another test?
Actually I get them on startup in chrome://browser/content/browser.xul so I don't think we need another test.
Assignee: nobody → tnikkel
Keywords: checkin-needed
Is there a test that might cause them to show up for more people, or is what makes them specific to some systems for browser.xul going to do the same for any other testcase?
I believe it is the same root problem as bug 486065. So browser.xul will show the problem if you have an affected configuration, but there isn't a different testcase that will trigger the problem for configurations that were unaffected by bug 486065.
Comment on attachment 394695 [details] [diff] [review]
patch?
[Checkin: Comment 5]


http://hg.mozilla.org/mozilla-central/rev/8ea02ebd43f0
Attachment #394695 - Attachment description: patch? → patch? [Checkin: Comment 5]
Status: NEW → RESOLVED
Closed: 11 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3
Is it worth getting this in on 1.9.2?
Target Milestone: mozilla1.9.3 → mozilla1.9.3a1
I guess we want this on 1.9.2 since it is a follow up to a 1.9.2 regression fix.
Flags: wanted1.9.2?
Attachment #394695 - Flags: approval1.9.2?
Attachment #394695 - Flags: approval1.9.2? → approval1.9.2+
Keywords: checkin-needed
Whiteboard: [needs 192 landing]
Flags: wanted1.9.2?
Flags: wanted1.9.2-
Flags: blocking1.9.2-
You need to log in before you can comment on or make changes to this bug.