Closed
Bug 136930
Opened 22 years ago
Closed 22 years ago
opening some mail folders causes infinite resize looping
Categories
(Core :: Layout, defect)
Tracking
()
VERIFIED
DUPLICATE
of bug 121583
People
(Reporter: blizzard, Assigned: hewitt)
References
Details
Build is from the Morning of Apr 11, 2002 off the 1.0.0 branch. When I open some of my mail folders the window will enter a state where the seperator bar will move up and down about 20 pixels over and over again. I can also trigger this by deleting mail in my folder. It seems to be related to the when the scrollbar is appearing and disappearing.
Comment 1•22 years ago
|
||
I have seen a similar problem to this for a while now on OS/2. Do you visually see the separator bouncing up and down? See bug: http://bugzilla.mozilla.org/show_bug.cgi?id=134698
Comment 2•22 years ago
|
||
I saw this last week. I resized the mail window slightly, and the next time I started up I no longer saw it, and haven't seen it since. I think it's fairly sensitive to the size of the mail window. (I believe mine was the default size when I was seeing the problem, and I resized it bigger, but it probably also depends on other factors like font size and mail message length). I did see the separator bouncing up and down.
Reporter | ||
Comment 3•22 years ago
|
||
This showed up in between the 2002-03-28-08 and 2002-03-29-21 builds on Linux. Here are all the checkins that seem to cover that period: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=mozilla%2F&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=03%2F28%2F2002+01%3A00%3A00&maxdate=03%2F29%2F2002+21%3A00%3A00&cvsroot=%2Fcvsroot That was the day that <outliner> was changed to <tree> which is the most likely candidate.
Comment 4•22 years ago
|
||
We really need to get this fixed for 1.0. Getting it into RC1 would be even better.
Keywords: mozilla1.0+,
nsbeta1
Comment 5•22 years ago
|
||
Adding to Make RC1 Not Suck. I've seen this too. Very visible.
Blocks: 134771
Comment 6•22 years ago
|
||
Maybe hewitt should take a look... Seems the most likely candidate to figure this out quickly.
Assignee: attinasi → hewitt
I think sspitzer had a bug on (and was investigating) some other recent regression related to some infinite loop. Maybe it's unrelated, though. I wasn't completely following it.
Reporter | ||
Comment 8•22 years ago
|
||
I just reproduced this on win98 pretty easily. I'm looking at and playing with code down in nsTreeBodyFrame.cpp, it's probably there.
OS: Linux → All
Reporter | ||
Comment 9•22 years ago
|
||
This is a race condition of some kind triggered by the stars lining up correctly with the right number of messages in a mailbox and the viewport being just the right size. I can usually do it in a mail folder that doesn't have many messages in it. I was able to cause this by loading the folder and then decreasing the size of the window slowly until the scrollbar appeared or opening the window slowly until the scrollbar disappears. If you cross that threshold in just the right way, this loop will happen. I've also seen it happen when I haven't touched the size of the toplevel window at all - it just happens when you click on a folder and it has the right number of messages in it. Here's what I know so far, given my limited knowledge of frames and layout: o nsSprocketLayout::Layout is calling down into nsTreeBodyFrame::SetBounds() with a new height. o CheckVerticalOverflow() is called from SetBounds(). o In CheckVerticalOverflow() the new height causes the scrollbar to be hidden so the event is posted that hides the scrollbar. In the next reflow pass, this happens again, except that the height is now small enough to show the scrollbar. CheckVerticalOverflow() posts an event which shows the scrollbar but this triggers another reflow which causes the scrollbar to be hidden and the process repeats ad infinitum. The real clue here is the very first reflow that happens when you open the folder the first time that sets the process off. Remember, I've seen this without ever changing the size of the toplevel window. The height of the nsTreeBodyFrame is changed when you open a folder that has the right number of messages in it, for no reason that I can see. However, I'm not smart enough to figure out who is increasing the height of the frame since it's already set when nsSprocketLayout::Layout() gets to it. (the larger size is found in aBox->GetClientRect() and is unchanged through the function.) Can someone help me figure out where mRect is changed through this process? My layout-fu is not strong.
Comment 10•22 years ago
|
||
we've seen this problem in other places before and could never figure out why or how. usually tweaking css would make it come and go, and we'd pray it would stay away longer the next time. box bug? grid bug? who knows. *sigh*
Reporter | ||
Comment 11•22 years ago
|
||
Well, here's your chance to find it for real. :)
Comment 13•22 years ago
|
||
*** Bug 129526 has been marked as a duplicate of this bug. ***
Comment 14•22 years ago
|
||
Nav triage team needs info: QA Wanted, need reproducible case. In the meantime, nsbeta1+/adt3 in case Joe can help.
Comment 15•22 years ago
|
||
This bug is not easy to reproduce. It does not seem to consistently occur. I can't help with working with the code as I don't have the necessary software. Getting a reproducible case could be a challenge. I believe it is related to when the scrollbar appears/disappears (confirming reporter's comment).
Comment 16•22 years ago
|
||
This is actually a dupe of bug 121583, which has been hidden and worked around by various places (Page info: bug 122055, Address book: bug 121566, Venkman: bug 121583 comment 14) bug 121583 has some discussion, a stack trace, and a slew of dupes...
Reporter | ||
Comment 17•22 years ago
|
||
*** This bug has been marked as a duplicate of 121583 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Comment 18•22 years ago
|
||
removing duplicate from RC1 list in favor of the original.
No longer blocks: 134771
Comment 19•22 years ago
|
||
vrfy dupe
You need to log in
before you can comment on or make changes to this bug.
Description
•