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)

x86
Windows NT
defect
Not set
critical

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)

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)
Keywords: crash
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.
*** Bug 94566 has been marked as a duplicate of this bug. ***
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...
Whiteboard: verify 94566 and 93974 after 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
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]
r=peterl
sr=attinasi - please make sure aWidget is checked for null before dereferencing
it though... Thanks.
fixed
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
doesn't appear to be crashing anymore - WinNT4 2001082303
verified in 8/24 build. great fix...
Status: RESOLVED → VERIFIED
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 → ---
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 ago23 years ago
Resolution: --- → FIXED
closing this one out....Jay, please log a new bug against the View system.
markinv VERIFIEd...

Jay is gonna file a separate bug on the View system problem.
Status: RESOLVED → VERIFIED
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.

Attachment

General

Creator:
Created:
Updated:
Size: