542 bytes, application/xhtml+xml
143.94 KB, text/plain
65.25 KB, text/plain
2.42 KB, patch
|Details | Diff | Splinter Review|
41.94 KB, text/plain
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
The scrollbar is a reflow root, but not a very good one...
Flags: blocking1.9? → blocking1.9-
Confirming it still happens with TRUNK. Attaching a debug from a startup of seamonkey. Maybe it helps someone.
Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007112921 SeaMonkey/2.0a1pre
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.
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
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.
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
Comment on attachment 332032 [details] [diff] [review] patch Please keep an eye out for performance issues!
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
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 → ---
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.
Still happens during startup in browser mode.
You need to log in before you can comment on or make changes to this bug.