Closed Bug 136930 Opened 22 years ago Closed 22 years ago

opening some mail folders causes infinite resize looping

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
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.
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
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.
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.
We really need to get this fixed for 1.0. Getting it into RC1 would be even better.
Keywords: mozilla1.0+, nsbeta1
Adding to Make RC1 Not Suck.  I've seen this too.  Very visible.
Blocks: 134771
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.
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
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.
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*
Well, here's your chance to find it for real. :)
Changing QA contact
QA Contact: petersen → amar
*** Bug 129526 has been marked as a duplicate of this bug. ***
Nav triage team needs info: QA Wanted, need reproducible case.  In the meantime,
nsbeta1+/adt3 in case Joe can help.
Keywords: nsbeta1 → nsbeta1+, qawanted
Whiteboard: [need info] [adt3]
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).
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...

*** This bug has been marked as a duplicate of 121583 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
removing duplicate from RC1 list in favor of the original.
No longer blocks: 134771
vrfy dupe
Status: RESOLVED → VERIFIED
Keywords: mozilla1.0+, nsbeta1+, qawanted
Whiteboard: [need info] [adt3]
You need to log in before you can comment on or make changes to this bug.