Read a msg and Minimizing Mail Window Pegs the CPU to 100%.

VERIFIED DUPLICATE of bug 40574

Status

P3
major
VERIFIED DUPLICATE of bug 40574
19 years ago
14 years ago

People

(Reporter: skasinathan, Assigned: eric)

Tracking

Trunk
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta2+])

(Reporter)

Description

19 years ago
Steps: 
1. Start mail using -mail and read a msg.
2. Minimize the Mail Window. The CPU usage to 100% and slows all other apps.

Build and Platform:
2000-04-11-09-M15 and  2000-04-12-06-M15. Windows NT.

Note: 
1. Peter Trudelle filed a similar kinda bug (35412) and he says that Seamonkey 
*freezes*. In my case it *does not* freezes.

2. If I restore the Mail window, the CPU usage is OK after a while (after 4-6 
seconds). 

3. If you weren't able to reproduce this bug, try clicking "get msg" and then 
minimizing the Mail window.

Comment 1

19 years ago
We are caught in an infinite reflow of a box frame in this scenario. Here's an
excerpt of the stack that I keep seeing whenever I break into the debugger after
the window has been minimized:
nsBox::SetBounds(nsBox * const 0x025e4954, nsBoxLayoutState & {...}, const
nsRect & {x=0 y=0 width=0 height=0}) line 211 + 13 bytes
nsBox::Collapse(nsBox * const 0x025e4954, nsBoxLayoutState & {...}) line 398
nsSprocketLayout::Layout(nsSprocketLayout * const 0x01853f20, nsIBox *
0x025e44f8, nsBoxLayoutState & {...}) line 369
nsContainerBox::Layout(nsContainerBox * const 0x025e44f8, nsBoxLayoutState &
{...}) line 489 + 34 bytes
nsBoxFrame::Layout(nsBoxFrame * const 0x025e44f8, nsBoxLayoutState & {...}) line 822
nsSprocketLayout::Layout(nsSprocketLayout * const 0x01853f20, nsIBox *
0x025e4464, nsBoxLayoutState & {...}) line 367
nsContainerBox::Layout(nsContainerBox * const 0x025e4464, nsBoxLayoutState &
{...}) line 489 + 34 bytes
nsBoxFrame::Layout(nsBoxFrame * const 0x025e4464, nsBoxLayoutState & {...}) line 822
nsSprocketLayout::Layout(nsSprocketLayout * const 0x01853f20, nsIBox *
0x0133dee0, nsBoxLayoutState & {...}) line 367
nsContainerBox::Layout(nsContainerBox * const 0x0133dee0, nsBoxLayoutState &
{...}) line 489 + 34 bytes
nsBoxFrame::Layout(nsBoxFrame * const 0x0133dee0, nsBoxLayoutState & {...}) line 822
nsStackLayout::Layout(nsStackLayout * const 0x01853450, nsIBox * 0x0133de4c,
nsBoxLayoutState & {...}) line 235
nsContainerBox::Layout(nsContainerBox * const 0x0133de4c, nsBoxLayoutState &
{...}) line 489 + 34 bytes
nsBoxFrame::Layout(nsBoxFrame * const 0x0133de4c, nsBoxLayoutState & {...}) line 822
nsBoxFrame::Reflow(nsBoxFrame * const 0x0133de14, nsIPresContext * 0x0284e060,
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 678
nsRootBoxFrame::Reflow(nsRootBoxFrame * const 0x0133de14, nsIPresContext *
0x0284e060, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0) line 206
nsContainerFrame::ReflowChild(nsIFrame * 0x0133de14, nsIPresContext *
0x0284e060, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0,
int 0, unsigned int 0, unsigned int & 0) line 613 + 31 bytes
ViewportFrame::Reflow(ViewportFrame * const 0x0133ddd8, nsIPresContext *
0x0284e060, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0) line 545
nsHTMLReflowCommand::Dispatch(nsHTMLReflowCommand * const 0x03607870,
nsIPresContext * 0x0284e060, nsHTMLReflowMetrics & {...}, const nsSize &
{width=0 height=0}, nsIRenderingContext & {...}) line 145
PresShell::ProcessReflowCommands(PresShell * const 0x02840d80, int 1) line 2315
ReflowEvent::HandleEvent() line 2215


You can see that the initial process reflow commands is entering the box reflow
and we never come out....Every time I break in the debugger I'm in a similar
stack trace.

re-assigning to evaughan
Assignee: selmer → evaughan

Updated

19 years ago
Severity: normal → major
Keywords: beta2

Updated

19 years ago
Keywords: nsbeta2

Comment 2

19 years ago
Putting on [nsbeta2+] radar.  
Keywords: beta2
Whiteboard: [nsbeta2+]
(Assignee)

Comment 3

19 years ago
targeting
Status: NEW → ASSIGNED
Target Milestone: --- → M16

Updated

19 years ago
Blocks: 40158

Updated

19 years ago
Target Milestone: M16 → M18

Comment 4

18 years ago

*** This bug has been marked as a duplicate of 40574 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE

Comment 5

18 years ago
vrfy dup
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.