Closed Bug 38872 Opened 24 years ago Closed 24 years ago

Minimize and Maximize to/from system tray causes crashes

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: selmer, Assigned: mikepinkerton)

Details

(Keywords: crash) 

About 30% of my attempts to minimize or maximize a window result in a crash.  I
have sent a number of talkback reports on this, but it doesn't go away.  This is
crashing way too frequently for an action that happens so often.  Please don't
just close this bug because you can't duplicate it in one or two attempts.  Use
the daily build from Sweetlou until you see this, then you'll believe.
I've held off filing this for quite a while, but it's getting worse now.
Keywords: crash
just wondering if this really belongs in XPApps...? :-)
QA Contact: sairuh → jrgm
Maybe event handling?  I haven't been able to build a debug build in quite a
while now, so I don't have a stack trace to use CVS Blame on...

Reassigning as per Don
Assignee: don → danm
Component: XPApps → XP Toolkit/Widgets
Keywords: nsbeta2
Well, I can't do this on win 95, but here is a representative stack trace
for a talkback filed by selmer@netscape.com with the described steps to 
reproduce.

nsMenuPopupFrame::AdjustClientXYForNestedDocuments 
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsMenuPopupFrame.cpp, line 291] 
nsMenuPopupFrame::SyncViewWithFrame 
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsMenuPopupFrame.cpp, line
534] 
nsPopupSetFrame::LayoutFinished 
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsPopupSetFrame.cpp, line 385] 
nsPopupSetFrame::Layout 
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsPopupSetFrame.cpp, line 236] 
nsSprocketLayout::Layout 
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsSprocketLayout.cpp, line 365] 
nsContainerBox::Layout 
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsContainerBox.cpp, line 525] 
nsBoxFrame::Layout 
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp, line 822] 
nsStackLayout::Layout 
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsStackLayout.cpp, line 237] 
nsContainerBox::Layout 
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsContainerBox.cpp, line 525] 
nsBoxFrame::Layout 
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp, line 822] 
nsBoxFrame::Reflow 
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp, line 678] 
nsRootBoxFrame::Reflow 
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsRootBoxFrame.cpp, line 207] 
nsContainerFrame::ReflowChild 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 
666] 
ViewportFrame::Reflow 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsViewportFrame.cpp, line 546] 
PresShell::ResizeReflow 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 1684] 
PresShell::ResizeReflow 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 3455] 
nsViewManager2::SetWindowDimensions 
[d:\builds\seamonkey\mozilla\view\src\nsViewManager2.cpp, line 437] 
nsViewManager2::DispatchEvent 
[d:\builds\seamonkey\mozilla\view\src\nsViewManager2.cpp, line 1293] 
HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 69] 
nsWindow::DispatchEvent 
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 531] 
nsWindow::DispatchWindowEvent 
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 548] 
nsWindow::OnResize [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, 
line 3228] 
nsWindow::ProcessMessage 
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2640] 
nsWindow::WindowProc 
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 781] 
USER32.dll + 0x19d0 (0x77e719d0) 
USER32.dll + 0x30a3 (0x77e730a3) 
ntdll.dll + 0x163a3 (0x77f763a3) 
DocumentViewerImpl::SetBounds 
[d:\builds\seamonkey\mozilla\layout\base\src\nsDocumentViewer.cpp, line 687] 
nsDocShell::SetPositionAndSize 
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 1393] 
nsWebShell::SetPositionAndSize 
[d:\builds\seamonkey\mozilla\webshell\src\nsWebShell.cpp, line 1610] 
nsWebShellWindow::HandleEvent 
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsWebShellWindow.cpp, line 414] 
nsWindow::DispatchEvent 
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 531] 
nsWindow::DispatchWindowEvent 
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 548] 
nsWindow::OnResize [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, 
line 3228] 
nsWindow::ProcessMessage 
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2640] 
nsWindow::WindowProc 
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 781] 
USER32.dll + 0x19d0 (0x77e719d0) 
USER32.dll + 0x30a3 (0x77e730a3) 
ntdll.dll + 0x163a3 (0x77f763a3) 
USER32.dll + 0x18d2 (0x77e718d2) 
nsWindow::DefaultWindowProc 
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 807] 
USER32.dll + 0x27fe (0x77e727fe) 
USER32.dll + 0x2889 (0x77e72889) 
nsWindow::WindowProc 
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 792] 
USER32.dll + 0x1820 (0x77e71820)  
based on the stack trace, this looks maybe like pinkerton. (possibly dup of
bug #31563 ? -- same stack, but different steps to reproduce).

Top of stack (Full stack trace already included above).

nsMenuPopupFrame::AdjustClientXYForNestedDocuments 
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsMenuPopupFrame.cpp, line 291] 
nsMenuPopupFrame::SyncViewWithFrame 
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsMenuPopupFrame.cpp, line
534] 
nsPopupSetFrame::LayoutFinished 
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsPopupSetFrame.cpp, line 385] 
nsPopupSetFrame::Layout 
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsPopupSetFrame.cpp, line 236]
Assignee: danm → pinkerton
Cool!  Thanks for pulling up the talkback stack.
hrm, all you do is minimize or maximize? i don't see how we can be in popup code 
if there's no popup. hrm.

accepting for m16.
Status: NEW → ASSIGNED
Target Milestone: --- → M16
The only way I could see a popup being involved is that something changed state
as I minimized/maximized.  One possibility is an alert from AIM or Mail, but
it's awfully coincidental that it waits until I maximize to kill me.

Some of steve's talkback comments referred to having a minimized browser window,
clicking on a URL in a mail message from messenger (which loads the URL in the
browser window) and then maximizing the browser window ... crash. (just FYI, 
that still doesn't make it a popup, though).
Using 2000 05 10 12, got this again and talkback incident TB10349171Y created.
In this case, I know there are no popups involved.  I had an active browser
window which was spinning the throbber at the end of a bugzilla bug change
submit (the throbber keeps running even though the page looks done.)  Nothing
else was going on, then I maximized my idle mail window and crashed immediately
(before anything could even paint.)

Definitely throbber related.  In addition, if the throbber is throbbing then
minimize/maximize can also cause different flavors of unresponsiveness from the
browser window.  Amazingly, mail continues to function most of the time.  What
I've seen is that all events to the window get dropped but the window will
repaint itself.  Many times, the cursor gets restricted and can't go into my
system tray area.  Bringing up task manager can usually free up the cursor, but
doesn't help the frozen window.

Sorry if this is more than one bug, I'm not sure how all this is related.

probably a dupe of 22427 (which is actually about NSPR events being lost in 
minimized windows). Not sure enough about that to actually mark it a dupe. Let's 
make Pink do it.

actually, this has to do with tooltips (hence the popups). once a tooltip is 
shown in the mail window, the app will crash when you minimize then maximize.

notes:

the frame cached in |mElementFrame| nsPopupSetFrame gets corrupted somehow after 
the window is minimized then restored. Before minimization, the debugger can tell 
that it's a frame in good standing (nsTreeItemFrame, for example). After 
restoring the window, the pointer hasn't changed value, but we can no longer tell 
what it is...the vtable no longer indicates it is a tree frame. I wonder if the 
tree is doing something weird with frames under the hood on the reflow.

Furthermore, this only happens with tooltips in the folderpane's tree. Tooltips 
on the buttons on the toolbar don't cause this crash.

cc'ing hyatt for his input on the behavior of trees.

never mind, i'll just let trees be trees and clear out |mElementFrame| when the 
popup goes away.

fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Awesome!  Thanks for the quick turnaround!


Works for Me
Platform: PC
OS: Windows 98
Mozilla Version: 2000100508

Marking as Verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.