"ASSERTION: non-root frame's desired size changed during an incremental reflow" when manipulating the contents of a scrollbar

REOPENED
Assigned to

Status

()

defect
REOPENED
13 years ago
7 years ago

People

(Reporter: jruderman, Assigned: dbaron)

Tracking

(Blocks 4 bugs, {assertion, testcase})

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
wanted1.9.1 +
blocking1.9 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments)

Reporter

Description

13 years ago
Posted file testcase
Loading the testcase triggers:

###!!! ASSERTION: non-root frame's desired size changed during an incremental reflow: 'target == root || (desiredSize.width == size.width && desiredSize.height == size.height)', file /Users/admin/trunk/mozilla/layout/base/nsPresShell.cpp, line 6201
Reporter

Updated

13 years ago
Blocks: 369038
The scrollbar is a reflow root, but not a very good one...
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9-

Comment 2

12 years ago
Confirming it still happens with TRUNK. Attaching a debug from a startup of seamonkey. Maybe it helps someone.

Comment 3

12 years ago
Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007112921 SeaMonkey/2.0a1pre

Comment 4

11 years ago
still occurs, maybe deserves a similar patch to bug #369418, jwatt?
It occurs to me that we could extend FrameNeedsReflow to allow a reflow root to be passed in, to support being a conditional reflow root.  Then scrollbars could act like reflow roots for scrolling, but not other things.
Asking wanted-1.9.1, since it's probably the single largest source of assertions in a normal Thunderbird session.
Flags: wanted1.9.1?
OS: Mac OS X → All
Hardware: Macintosh → All
It surprises me that this bug would lead to assertions in normal use.
Summary: "ASSERTION: non-root frame's desired size changed during an incremental reflow" → "ASSERTION: non-root frame's desired size changed during an incremental reflow" when manipulating the contents of a scrollbar
Reporter

Comment 8

11 years ago
So you think the issue with Thunderbird might be a different bug?
It seems likely; somebody should debug and look at what type of frame it is asserting about.
It's asserting about a scrollbar.  Basically, this assert will get triggered any time a collapsed scrollbar is reflowed for some reason (because collapsed XUL boxes ignore the reflow state and just return 0x0 for the size).  So all that needs to happen is to somehow trigger reflow of the collapsed scrollbar.  Thunderbird manages to do this quite regularly.
Well, reflowing a collapsed scrollbar is still different from poking inside the guts of one.

That said, I'm not sure why that would trigger the assertion; we ought to put 0x0 in the reflow state if that's the current size.

Updated

11 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.xul → xptoolkit.widgets
So I think we should just stop making scrollbars be reflow roots.

I thought a bit about adding a reflow root argument to FrameNeedsReflow.  However, that would have the bug that if FrameNeedsReflow were called twice in succession, once with the root and once without the root, the second call would bail because the frame was already dirty.
Assignee: nobody → dbaron
Posted patch patchSplinter Review
Attachment #332032 - Flags: superreview?(bzbarsky)
Attachment #332032 - Flags: review?(bzbarsky)
Comment on attachment 332032 [details] [diff] [review]
patch

Please keep an eye out for performance issues!
Attachment #332032 - Flags: superreview?(bzbarsky)
Attachment #332032 - Flags: superreview+
Attachment #332032 - Flags: review?(bzbarsky)
Attachment #332032 - Flags: review+
Landed:
http://hg.mozilla.org/mozilla-central/index.cgi/rev/85a9eb44b240
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1a2
I backed this out due to bug 449221.  (There's also bug 449338 that I haven't had a chance to look at.)

I think what we need to do here is make things that move the slider simply move it and repaint it, without actually using reflow code.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla1.9.1a2 → ---
Flags: blocking1.9.1?
I would like scrollbars to just be single elements without internal structure. That would simplify native-themed scrollbars (the vast majority of cases).
So we can't fix this bug until that happens?
Of course we can fix this bug another way before that happens. The only question is whether it's worth doing --- if someone's going to spend some time reworking the thumb code, maybe they'd be better off doing the larger reworking of scrollbars. But that's really up to whoever's interested in doing the work.
Reporter

Updated

11 years ago
Blocks: 430887
Flags: wanted1.9.1?
Flags: wanted1.9.1+
Flags: blocking1.9.1?

Comment 20

10 years ago
Still happens during startup in browser mode.

Updated

7 years ago
Blocks: 450974
You need to log in before you can comment on or make changes to this bug.