Closed
Bug 94546
Opened 23 years ago
Closed 23 years ago
crash when hitting back button before print OK is hit - Trunk [@ nsViewManager::ProcessPendingUpdates] [@ nsCOMPtr_base::assign_assuming_AddRef]
Categories
(Core :: Printing: Output, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: tever, Assigned: dcone)
References
()
Details
(Keywords: crash, topcrash, Whiteboard: verify 94566 and 93974 after this is fixed)
Crash Data
Attachments
(1 file)
920 bytes,
patch
|
Details | Diff | Splinter Review |
Overview Description: If you hit the back button quickly after printing (while the print dialog is still present), the browser crashes. Steps to Reproduce: 1.) Go to the URL. 2.) Select a link to display a particular song. The 'PL' links usually work. 3.) select file | print - the print dialog appears 4.) press OK 4.) quickly press the back button before the print dialog disappears Actual Results: crash Build Date & Platform Bug Found: trunk 2001080804 win NT Additional Builds and Platforms Tested On: haven't tested Additional Information: This is spun off of bug 90060. Steps are almost the same but the stack trace is different. Must hit back before print dialog disappears. Easily reproducable for me. Talkback incident id 33859563 Call Stack: (Signature = nsCOMPtr_base::assign_assuming_AddRef 6c1fdb35) nsCOMPtr_base::assign_assuming_AddRef [..\..\..\dist\include\nsCOMPtr.h, line 421] GlobalWindowImpl::Print [d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 1863] XPTC_InvokeByIndex [d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp, line 139] XPCWrappedNative::CallMethod [d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp, line 1884] XPC_WN_CallMethod [d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp, line 1253] js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 809] js_Interpret [d:\builds\seam js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 825] js_InternalInvoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 897] JS_CallFunctionValue [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 3351] nsJSContext::CallEventHandler [d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 949] nsJSEventListener::HandleEvent [d:\builds\seamonkey\mozilla\dom\src\events\nsJSEventListener.cpp, line 140] nsEventListenerManager::HandleEventSubType [d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line 1197] nsEventListenerManager::HandleEvent [d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line 2189] nsXULElement::HandleDOMEvent [d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3698] PresShell::HandleDOMEventWithTarget [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5696] nsMenuFrame::Execute [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsMenuFrame.cpp, line 1538] nsMenuFrame::HandleEvent [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsMenuFrame.cpp, line 439] PresShell::HandleEventInternal [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5665] PresShell::HandleEvent [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5575] nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 377] nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 350] nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 350] nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 350] nsViewManager::DispatchEvent [d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 2058] HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 68] nsWindow::DispatchEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 725] nsWindow::DispatchWindowEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 742] nsWindow::DispatchMouseEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4248] ChildWindow::DispatchMouseEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4495] nsWindow::ProcessMessage [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3240] nsWindow::WindowProc [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 990] USER32.dll + 0x1268 (0x77e71268)
Assignee | ||
Comment 1•23 years ago
|
||
you can actually hit the back button before the you hit ok, that will crash ever y time. This problem seems to have to do with the URL getting switched out before the ok button on the print is processed.
another way to make it crash: 1) launch netscape 2) jump to http://www.sjc.org 3) click on "Maps & Parking" in left hand side 4) scroll down and click on "Pick/Drop off locations and Parking Lots" 5) in that new window, File | Print I'll make sure this gets tested when this is fixed...
updating summary
Summary: crash when hitting back button after printing → crash when hitting back button before print OK is hit.
Easy to trigger by accident. Transferring keywords and severity.
Severity: normal → critical
Keywords: mozilla0.9.4,
nsbeta1
Comment 6•23 years ago
|
||
Adding topcrash keyword and Trunk [@ nsViewManager::ProcessPendingUpdates] [@ nsCOMPtr_base::assign_assuming_AddRef] to the summary for tracking. Both of those crashes are in the latest MozillaTrunk topcrash Talkback reports.
Keywords: topcrash
Summary: crash when hitting back button before print OK is hit. → crash when hitting back button before print OK is hit - Trunk [@ nsViewManager::ProcessPendingUpdates] [@ nsCOMPtr_base::assign_assuming_AddRef]
Assignee | ||
Comment 7•23 years ago
|
||
Comment 8•23 years ago
|
||
r=peterl
Comment 9•23 years ago
|
||
sr=attinasi - please make sure aWidget is checked for null before dereferencing it though... Thanks.
Assignee | ||
Comment 10•23 years ago
|
||
fixed
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 11•23 years ago
|
||
doesn't appear to be crashing anymore - WinNT4 2001082303
Comment 13•23 years ago
|
||
Talkback data is showing a lot of crashes with recent MozillaTrunk builds in nsViewManager::ProcessPendingUpdates 4b3d5b1d http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/view/src/nsViewManager.cpp line 1638 None of the comments mention printing, so it might be a different problem, but the stack is identical to the one reported in bug 94566 (which was marked a dup of this one). Reopening for now, but before I add too much info in this bug, here is the most recent incident: Incident ID 34640561 Stack Signature nsViewManager::ProcessPendingUpdates 4b3d5b1d Bug ID Trigger Time 2001-08-28 13:19:34 Email Address ssaux@netscape.com User Comments Build ID 2001082809 Product ID MozillaTrunk Platform ID Win32 Trigger Reason Access violation Stack Trace nsViewManager::ProcessPendingUpdates [d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1638] nsViewManager::FlushPendingInvalidates [d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 3829] nsViewManager::ProcessInvalidateEvent [d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 3837] nsInvalidateEvent::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 145] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 591] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 524] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1072] If this is a regression, I'll update the bug with more Talkback info...otherwise, let me know and I can log a new bug.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 14•23 years ago
|
||
This one is not that bug, maybee the other one needed to be opened.. this one definetly has a different stack. If the comments did not mention printing.. I would open another bug, this bug was reproduced and clobbered and verified. Even the other bug was verified. There can be bugs that crash with different causes. A good example of this was that when the nsDocumentViewer was being destroyed before it was finished being used. The printing case was fixed but plugins were not and there were other cases that had close, but not the same symptoms. Please log a new bug.. and assign to the View system.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 15•23 years ago
|
||
closing this one out....Jay, please log a new bug against the View system.
Comment 16•23 years ago
|
||
markinv VERIFIEd... Jay is gonna file a separate bug on the View system problem.
Status: RESOLVED → VERIFIED
Updated•13 years ago
|
Crash Signature: [@ nsViewManager::ProcessPendingUpdates]
[@ nsCOMPtr_base::assign_assuming_AddRef]
You need to log in
before you can comment on or make changes to this bug.
Description
•