Closed Bug 154021 Opened 22 years ago Closed 22 years ago

expanding a largely populated To: field where it expands over the message body causes 100% cpu useage

Categories

(SeaMonkey :: MailNews: Message Display, defect)

x86
Windows XP
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 128809

People

(Reporter: esther, Assigned: ssu0262)

Details

(Keywords: hang)

Attachments

(1 file)

Using branch build 20020618 on winxp, if you expand the To: field of a mail
message with so many names that the To: list drops over the message body you
will see the cup usage go up to 100%.  This bug has been showing up recently and
is hard to narrow down, but for internal users the weekly msg from Jing usually
with an attached .pdf file will show this problem.  I'm still trying to find out
if I can fake a mail message with that many reciipents to see if we can
reproduce this without that particular message.  I don't think the attachment is
necessary other than it takes up space in the header so the To: list has to drop
into the message pane to display all of them.  This happens on IMAP and POP
dredd accoutns in addition to the AOL account mentiond in bugscape bug 16979,
but so far only on Windows.

Steps to reproduce using Jing's messages.

1. launch app
2. Open your mail account that would contain the message mentioned above.
3. Move the divider bar between the thread pane and message pane down so that
when you click on the twisty to the To field the list will expand into the
message body area.  

At this point, my cpu useage shot up to 100%, sometimes you can get out of this,
but most times you can't.  And in my case when testing this, I did Ctrl+Alt+del
enough times desperately that when the app closed, my prefs.js file was
destroyed.  I found this out when I launched my profile again after CTRL+ALT+Del
I had no mail accounts or any bookmarks or preference settings.  Fortunately I
did have a back up of my prefs.js file so I could recover.
Please if you are going to play around with this back up your prefs.js file first.

Work around: Make sure your splitter bar is high enough that if you expand the
twisty for the To: list the whole header area (grey area) of the message is above 
the message pane.
Yes, use a test msg if you can.  We CANNOT attach Jing's message to this bug report.
Summary: expanding a largely populated To: field where it expands over the message body causes 100% cpu useage → expanding a largely populated To: field where it expands over the message body causes 100% cpu useage
Weird! For me, it seemed that I can only reproduce this problem on AOL accounts 
as I describe on comment5 of bugscape 16979:
http://bugscape.mcom.com/show_bug.cgi?id=16979#c5
I saw a little window redraw problem for dredd, but no hang for dredd (CPU went 
up to 100% but will be back to normal)...probably because I tested on 
Windows 2000.....
Save this file to your windows desktop and rename it longlist  with no
extension.  Then place it in your Profile Mail Local Folders directory.  Launch
app and then select that folder.  You should see 3 mail messages.
I have added (3) more messages in the test account that don't have
-attachments-, and can reproduce the probem selecting only those messages.  So
-attachments- doesn't appear to be necessary.
For internal users, you can log into 3qatest07 as IMAP and go to "longlist"
folder.  It contains messages that cause this problem.
Note: another key to reproducing is that in step 3, the narrowed thread pane
should have no scroll bar. So if you use 3qatest07 test account, you may need to
do a quick search on "testing a message with no attachment-" this will put 3
messages in the new thread window and then you should be able to create the
conditions for this to happen by shortening the heigth of the message pane,
allow all 3 messages to list without a scroll bar and then expand the To: twisty
on any of the messages to see the problem. 
For AOL accounts, this problem should be treated more critical:
Since AOL use New Mail folder for getting new message, and AOL clean msgs 
periodically -- this will make top part of the thread pane "no scroll bar" more 
frequently and AOL users will encounter CPU 100% hang more easily.
I am adding keywords hang and nominating nsbeta1 for this bug.
Keywords: hang, nsbeta1
reassigning to ssu.  Sean, could you look into this?
Assignee: sspitzer → ssu
sure, looking into this now.
Status: NEW → ASSIGNED
I was finally able to recreate this - I had to make it so that expanding the
message list would cause the thread pane to require a scroll bar, when it didn't
have one before, because the message pane would grow and take up some of the
thread pane. I'm pretty sure this is the infinite reflow problem, caused by the
reflow required when the thread pane gets a scroll bar when it didn't have one
before. This was fixed for some other instance by fooling around with the
scrollbar specification - I don't know if that would fix this instance or not.
I think bug 128809 is probably the same as this.

Here's a stack trace of the reflow happening in layout:

nsLineLayout::ReflowFrame(nsIFrame * 0x059f6e68, unsigned int & 0x00000492,
nsHTMLReflowMetrics * 0x00000000, int & 0x00000000) line 1068 + 27 bytes
nsBlockFrame::ReflowInlineFrame(nsBlockReflowState & {...}, nsLineLayout &
{...}, nsLineList_iterator {...}, nsIFrame * 0x059f6e68, unsigned char *
0x0012d453) line 3745 + 22 bytes
nsBlockFrame::DoReflowInlineFrames(nsBlockReflowState & {...}, nsLineLayout &
{...}, nsLineList_iterator {...}, int * 0x0012db90, unsigned char * 0x0012d953,
int 0x00000000, int 0x00000000) line 3621 + 32 bytes
nsBlockFrame::DoReflowInlineFramesAuto(nsBlockReflowState & {...},
nsLineList_iterator {...}, int * 0x0012db90, unsigned char * 0x0012d953, int
0x00000000, int 0x00000000) line 3511 + 46 bytes
nsBlockFrame::ReflowInlineFrames(nsBlockReflowState & {...}, nsLineList_iterator
{...}, int * 0x0012db90, int 0x00000000, int 0x00000000) line 3455 + 36 bytes
nsBlockFrame::ReflowLine(nsBlockReflowState & {...}, nsLineList_iterator {...},
int * 0x0012db90, int 0x00000000) line 2609 + 33 bytes
nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & {...}) line 2253 + 31 bytes
nsBlockFrame::Reflow(nsBlockFrame * const 0x03ca0b1c, nsIPresContext *
0x03162f88, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0x00000000) line 949 + 15 bytes
nsBoxToBlockAdaptor::Reflow(nsBoxLayoutState & {...}, nsIPresContext *
0x03162f88, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0x00000000, int 0x000004d0, int 0x00000000, int 0x0000215f, int
0x00000b6d, int 0x00000001) line 882
nsBoxToBlockAdaptor::DoLayout(nsBoxToBlockAdaptor * const 0x03e8a9cc,
nsBoxLayoutState & {...}) line 625 + 46 bytes
nsBox::Layout(nsBox * const 0x03e8a9cc, nsBoxLayoutState & {...}) line 1062
nsSprocketLayout::ChildResized(nsIBox * 0x03ca05fc, nsBoxLayoutState & {...},
nsIBox * 0x03e8a9cc, nsBoxSize * 0x03d42480, nsComputedBoxSize * 0x03d424c8,
nsBoxSize * 0x03d42430, nsComputedBoxSize * 0x03d424a8, const nsRect & {...},
nsRect & {...}, nsRect & {...}, int 0x00000001, int & 0x00000000) line 1109
nsSprocketLayout::Layout(nsSprocketLayout * const 0x01ca31e8, nsIBox *
0x03ca05fc, nsBoxLayoutState & {...}) line 555
nsContainerBox::DoLayout(nsContainerBox * const 0x03ca05fc, nsBoxLayoutState &
{...}) line 605 + 34 bytes
nsBoxFrame::DoLayout(nsBoxFrame * const 0x03ca05fc, nsBoxLayoutState & {...})
line 1210
nsBox::Layout(nsBox * const 0x03ca05fc, nsBoxLayoutState & {...}) line 1062
nsSprocketLayout::Layout(nsSprocketLayout * const 0x01ca31e8, nsIBox *
0x03cf3f68, nsBoxLayoutState & {...}) line 528
nsContainerBox::DoLayout(nsContainerBox * const 0x03cf3f68, nsBoxLayoutState &
{...}) line 605 + 34 bytes
nsBoxFrame::DoLayout(nsBoxFrame * const 0x03cf3f68, nsBoxLayoutState & {...})
line 1210
nsBox::Layout(nsBox * const 0x03cf3f68, nsBoxLayoutState & {...}) line 1062
nsSprocketLayout::Layout(nsSprocketLayout * const 0x01ca31e8, nsIBox *
0x03cece40, nsBoxLayoutState & {...}) line 528
nsContainerBox::DoLayout(nsContainerBox * const 0x03cece40, nsBoxLayoutState &
{...}) line 605 + 34 bytes
nsBoxFrame::DoLayout(nsBoxFrame * const 0x03cece40, nsBoxLayoutState & {...})
line 1210
nsBox::Layout(nsBox * const 0x03cece40, nsBoxLayoutState & {...}) line 1062
nsSprocketLayout::Layout(nsSprocketLayout * const 0x01ca31e8, nsIBox *
0x03cd1be8, nsBoxLayoutState & {...}) line 528
nsContainerBox::DoLayout(nsContainerBox * const 0x03cd1be8, nsBoxLayoutState &
{...}) line 605 + 34 bytes
nsBoxFrame::DoLayout(nsBoxFrame * const 0x03cd1be8, nsBoxLayoutState & {...})
line 1210
nsBox::Layout(nsBox * const 0x03cd1be8, nsBoxLayoutState & {...}) line 1062
nsSprocketLayout::Layout(nsSprocketLayout * const 0x01ca31e8, nsIBox *
0x03ccdb08, nsBoxLayoutState & {...}) line 528
nsContainerBox::DoLayout(nsContainerBox * const 0x03ccdb08, nsBoxLayoutState &
{...}) line 605 + 34 bytes
nsBoxFrame::DoLayout(nsBoxFrame * const 0x03ccdb08, nsBoxLayoutState & {...})
line 1210
nsBox::Layout(nsBox * const 0x03ccdb08, nsBoxLayoutState & {...}) line 1062
nsSprocketLayout::ChildResized(nsIBox * 0x03c8de88, nsBoxLayoutState & {...},
nsIBox * 0x03ccdb08, nsBoxSize * 0x03d3f7d8, nsComputedBoxSize * 0x03d3f830,
nsBoxSize * 0x03d3f760, nsComputedBoxSize * 0x03d3f800, const nsRect & {...},
nsRect & {...}, nsRect & {...}, int 0x00000004, int & 0x00000000) line 1109
nsSprocketLayout::Layout(nsSprocketLayout * const 0x01ca31e8, nsIBox *
0x03c8de88, nsBoxLayoutState & {...}) line 555
nsContainerBox::DoLayout(nsContainerBox * const 0x03c8de88, nsBoxLayoutState &
{...}) line 605 + 34 bytes
nsBoxFrame::DoLayout(nsBoxFrame * const 0x03c8de88, nsBoxLayoutState & {...})
line 1210
nsBox::Layout(nsBox * const 0x03c8de88, nsBoxLayoutState & {...}) line 1062
nsSprocketLayout::ChildResized(nsIBox * 0x03c8d954, nsBoxLayoutState & {...},
nsIBox * 0x03c8de88, nsBoxSize * 0x03d3f718, nsComputedBoxSize * 0x03d3f750,
nsBoxSize * 0x03d3f6f0, nsComputedBoxSize * 0x03d3f740, const nsRect & {...},
nsRect & {...}, nsRect & {...}, int 0x00000001, int & 0x00000000) line 1109
nsSprocketLayout::Layout(nsSprocketLayout * const 0x01ca31e8, nsIBox *
0x03c8d954, nsBoxLayoutState & {...}) line 555
nsContainerBox::DoLayout(nsContainerBox * const 0x03c8d954, nsBoxLayoutState &
{...}) line 605 + 34 bytes
nsBoxFrame::DoLayout(nsBoxFrame * const 0x03c8d954, nsBoxLayoutState & {...})
line 1210
nsBox::Layout(nsBox * const 0x03c8d954, nsBoxLayoutState & {...}) line 1062
nsSprocketLayout::Layout(nsSprocketLayout * const 0x01ca31e8, nsIBox *
0x03c82ebc, nsBoxLayoutState & {...}) line 528
nsContainerBox::DoLayout(nsContainerBox * const 0x03c82ebc, nsBoxLayoutState &
{...}) line 605 + 34 bytes
nsBoxFrame::DoLayout(nsBoxFrame * const 0x03c82ebc, nsBoxLayoutState & {...})
line 1210
nsBox::Layout(nsBox * const 0x03c82ebc, nsBoxLayoutState & {...}) line 1062
nsSprocketLayout::Layout(nsSprocketLayout * const 0x01ca31e8, nsIBox *
0x03311158, nsBoxLayoutState & {...}) line 528
nsContainerBox::DoLayout(nsContainerBox * const 0x03311158, nsBoxLayoutState &
{...}) line 605 + 34 bytes
nsBoxFrame::DoLayout(nsBoxFrame * const 0x03311158, nsBoxLayoutState & {...})
line 1210
nsBox::Layout(nsBox * const 0x03311158, nsBoxLayoutState & {...}) line 1062
nsStackLayout::Layout(nsStackLayout * const 0x01c9b430, nsIBox * 0x03310ebc,
nsBoxLayoutState & {...}) line 331
nsContainerBox::DoLayout(nsContainerBox * const 0x03310ebc, nsBoxLayoutState &
{...}) line 605 + 34 bytes
nsBoxFrame::DoLayout(nsBoxFrame * const 0x03310ebc, nsBoxLayoutState & {...})
line 1210
nsBox::Layout(nsBox * const 0x03310ebc, nsBoxLayoutState & {...}) line 1062
nsBoxFrame::Reflow(nsBoxFrame * const 0x03310e84, nsIPresContext * 0x03162f88,
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int &
0x00000000) line 1002
nsRootBoxFrame::Reflow(nsRootBoxFrame * const 0x03310e84, nsIPresContext *
0x03162f88, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0x00000000) line 242
nsContainerFrame::ReflowChild(nsIFrame * 0x03310e84, nsIPresContext *
0x03162f88, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int
0x00000000, int 0x00000000, unsigned int 0x00000000, unsigned int & 0x00000000)
line 802 + 31 bytes
ViewportFrame::Reflow(ViewportFrame * const 0x03310d30, nsIPresContext *
0x03162f88, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0x00000000) line 577
IncrementalReflow::Dispatch(nsIPresContext * 0x03162f88, nsHTMLReflowMetrics &
{...}, const nsSize & {...}, nsIRenderingContext & {...}) line 942
PresShell::ProcessReflowCommands(int 0x00000001) line 6422
ReflowEvent::HandleEvent() line 6279
HandlePLEvent(ReflowEvent * 0x05991358) line 6293
PL_HandleEvent(PLEvent * 0x05991358) line 596 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x01528388) line 526 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x0002049a, unsigned int 0x0000c145, unsigned int
0x00000000, long 0x01528388) line 1077 + 9 bytes
USER32! 77e12e98()
USER32! 77e130e0()
USER32! 77e15824()
nsAppShellService::Run(nsAppShellService * const 0x01af04c0) line 458
main1(int 0x00000001, char * * 0x00308100, nsISupports * 0x00000000) line 1456 +
32 bytes
main(int 0x00000001, char * * 0x00308100) line 1805 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
this is definitely a dupe of bug 128809.  marking as so.  There are already
patches on the other bug, but none seem to work so far (I just tried them).

*** This bug has been marked as a duplicate of 128809 ***
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
verified dup
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: