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

REOPENED
Assigned to

Status

()

Core
XUL
REOPENED
11 years ago
5 years ago

People

(Reporter: Jesse Ruderman, Assigned: dbaron)

Tracking

(Blocks: 4 bugs, {assertion, testcase})

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

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments)

(Reporter)

Description

11 years ago
Created attachment 251263 [details]
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

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

Comment 2

10 years ago
Created attachment 290748 [details]
seamonkey-gdb-run.txt

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

Comment 3

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

Comment 4

9 years ago
Created attachment 315730 [details]
current cvs HEAD stacktrace

still occurs, maybe deserves a similar patch to bug #369418, jwatt?
(Assignee)

Comment 5

9 years ago
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
(Assignee)

Comment 7

9 years ago
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

9 years ago
So you think the issue with Thunderbird might be a different bug?
(Assignee)

Comment 9

9 years ago
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.
(Assignee)

Comment 11

9 years ago
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

9 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.xul → xptoolkit.widgets
(Assignee)

Comment 12

9 years ago
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
(Assignee)

Comment 13

9 years ago
Created attachment 332032 [details] [diff] [review]
patch
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+
(Assignee)

Comment 15

9 years ago
Landed:
http://hg.mozilla.org/mozilla-central/index.cgi/rev/85a9eb44b240
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1a2
Depends on: 449221
Depends on: 449338
(Assignee)

Comment 16

9 years ago
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 → ---
(Assignee)

Updated

9 years ago
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).
(Assignee)

Comment 18

9 years ago
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

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

Comment 20

8 years ago
Created attachment 392049 [details]
current comm-central/seamonkey TIP stacktrace

Still happens during startup in browser mode.

Updated

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