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)
Tracking
()
VERIFIED
FIXED
M16
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.
Reporter | ||
Comment 1•24 years ago
|
||
I've held off filing this for quite a while, but it's getting worse now.
Keywords: crash
Comment 2•24 years ago
|
||
just wondering if this really belongs in XPApps...? :-)
QA Contact: sairuh → jrgm
Reporter | ||
Comment 3•24 years ago
|
||
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...
Comment 4•24 years ago
|
||
Reassigning as per Don
Comment 5•24 years ago
|
||
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)
Comment 6•24 years ago
|
||
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
Reporter | ||
Comment 7•24 years ago
|
||
Cool! Thanks for pulling up the talkback stack.
Assignee | ||
Comment 8•24 years ago
|
||
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
Reporter | ||
Comment 9•24 years ago
|
||
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.
Comment 10•24 years ago
|
||
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).
Reporter | ||
Comment 11•24 years ago
|
||
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.)
Reporter | ||
Comment 12•24 years ago
|
||
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.
Comment 13•24 years ago
|
||
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.
Assignee | ||
Comment 14•24 years ago
|
||
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.
Assignee | ||
Comment 15•24 years ago
|
||
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.
Assignee | ||
Comment 16•24 years ago
|
||
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
Reporter | ||
Comment 17•24 years ago
|
||
Awesome! Thanks for the quick turnaround!
Comment 18•24 years ago
|
||
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.
Description
•