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

Status: NEW

(Core :: XUL, defect)

Description

[Jesse Ruderman]

Attachment: 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

Comment 1

[Boris Zbarsky [:bzbarsky]]

The scrollbar is a reflow root, but not a very good one...

Comment 2

[Martin Mokrejs]

Attachment: seamonkey-gdb-run.txt

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

Comment 3

[Martin Mokrejs]

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

Comment 4

[Martin Mokrejs]

Attachment: current cvs HEAD stacktrace

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

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 6

[Joshua Cranmer [:jcranmer]]

Asking wanted-1.9.1, since it's probably the single largest source of assertions in a normal Thunderbird session.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It surprises me that this bug would lead to assertions in normal use.

Comment 8

[Jesse Ruderman]

So you think the issue with Thunderbird might be a different bug?

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It seems likely; somebody should debug and look at what type of frame it is asserting about.

Comment 10

[Boris Zbarsky [:bzbarsky]]

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.

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch

Comment 14

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 332032 [details] [diff] [review]
patch

Please keep an eye out for performance issues!

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Landed:
http://hg.mozilla.org/mozilla-central/index.cgi/rev/85a9eb44b240

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I would like scrollbars to just be single elements without internal structure. That would simplify native-themed scrollbars (the vast majority of cases).

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

So we can't fix this bug until that happens?

Comment 19

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 20

[Martin Mokrejs]

Attachment: current comm-central/seamonkey TIP stacktrace

Still happens during startup in browser mode.