User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Linux 2.4.20-4GB i686) Opera 7.11 [en] Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv: 1.4) Gecko/20030624 When a page contains following lines, it crashes when answering 'Cancel' for both of the window.print() dialogs. This happens in both cases: * these lines are in a complex server-built web-page (the form contains a hidden value too * these lines appear solely in a static html containing nothing else. Mozilla provides no error, but windows pops up a message saying that mozilla.exe has produced errors and needs to close (the standard error message). After that Netscape Talkback activates (i have sent this info to them). <form> <input type=submit name=test value=test onClick="window.print();window.print(); "> </form> This bug does not appear if the second window.print() was removed. As this kind of code could be useful (e.g. in case of having to print the same page to two different printers and then reload the same page again for a server script to refresh data) i thing mozilla should be able to survive this and not to crash. Reproducible: Always Steps to Reproduce: 1. enter the URL for any page, containing mentioned lines 2. Press the Test button 3. Press 'Cancel' for the first time 4. Perss 'Cancel' for the second time Actual Results: After that all open mozilla windows (including MailNews) disappear and windows pops up an error message. Expected Results: it should have just continued to load new page OS: Windows 2000 CPU: AMD Athlon XP 1800+ Mem: 256 MB

Testcase crashes with Mozilla 2003082903 on Mac OS 10.1.5. Rather old build..., will attach crash log. Laas, can you please post the Talkback ID for the incident? You'll find the ID if you start Talkback (by running "talkback.exe").

I can reproduce this on Win2k on Mozilla 1.5b (2003082704). Talkback incident ID TB23423173W submitted. Can't find any dupes (even in the large number of unconfirmed crashers associated with printing) so confirming this as NEW.

Also setting the component to "Printing" rather than "Browser - General". Note that if you insert a JavaScript alert() call between the two calls to window.print() it will work. I think it may be a timing issue. Using Ctrl+P to bring up the print dialog and cancelling it repeatedly also fails to crash Mozilla.

--> to default owner

I don't know if this helps, but I just discovered another test case. You have to load a HTML-file into composer, which includes <img src="test.jpg" onload="window.print();">. While opening this file, the print-dialog appears first, select "cancel". Then open for example the edit-dialog and after closing this, the print-dialog appears again. After cancelling Mozilla crashes. Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.4) Gecko/20030624 Alex.

I can confirm this crash in a homebrew 20031210 GCC build on WinXP. Attached is the (long) full stack trace from gdb.

Win2k stack: cccccccc() nsPrintEngine::SetIsPrinting(int 0) line 3912 nsPrintEngine::CleanupOnFailure(unsigned int 2147500036, int 1) line 2214 nsPrintEngine::Print(nsPrintEngine * const 0x041f0308, nsIPrintSettings * 0x2867cdf8, nsIWebProgressListener * 0x00000000) line 787 + 14 bytes DocumentViewerImpl::Print(DocumentViewerImpl * const 0x04399b50, nsIPrintSettings * 0x2867cdf8, nsIWebProgressListener * 0x00000000) line 3089 + 26 bytes GlobalWindowImpl::Print(GlobalWindowImpl * const 0x042caddc) line 2592 XPTC_InvokeByIndex(nsISupports * 0x042caddc, unsigned int 72, unsigned int 0, nsXPTCVariant * 0x0012dcb4) line 102 XPCWrappedNative::CallMethod(XPCCallContext & {...}, XPCWrappedNative::CallMode CALL_METHOD) line 2022 + 42 bytes XPC_WN_CallMethod(JSContext * 0x042cb020, JSObject * 0x03943418, unsigned int 0, long * 0x0664c6dc, long * 0x0012df84) line 1272 + 14 bytes js_Invoke(JSContext * 0x042cb020, unsigned int 0, unsigned int 0) line 941 + 23 bytes js_Interpret(JSContext * 0x042cb020, long * 0x0012e8b8) line 2962 + 15 bytes js_Invoke(JSContext * 0x042cb020, unsigned int 1, unsigned int 2) line 958 + 13 bytes js_InternalInvoke(JSContext * 0x042cb020, JSObject * 0x037e8598, long 58623408, unsigned int 0, unsigned int 1, long * 0x0012eb00, long * 0x0012e9dc) line 1035 + 20 bytes JS_CallFunctionValue(JSContext * 0x042cb020, JSObject * 0x037e8598, long 58623408, unsigned int 1, long * 0x0012eb00, long * 0x0012e9dc) line 3579 + 31 bytes nsJSContext::CallEventHandler(nsJSContext * const 0x042c9cd8, void * 0x037e8598, void * 0x037e85b0, unsigned int 1, void * 0x0012eb00, int * 0x0012eb04) line 1259 + 33 bytes nsJSEventListener::HandleEvent(nsJSEventListener * const 0x03e8f970, nsIDOMEvent * 0x28b987e0) line 178 + 69 bytes nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x040435e8, nsIDOMEvent * 0x28b987e0, nsIDOMEventTarget * 0x040bd770, unsigned int 4, unsigned int 7) line 1420 + 20 bytes nsEventListenerManager::HandleEvent(nsEventListenerManager * const 0x05b13ba0, nsIPresContext * 0x042255d0, nsEvent * 0x0012f208, nsIDOMEvent * * 0x0012eeec, nsIDOMEventTarget * 0x040bd770, unsigned int 7, nsEventStatus * 0x0012f568) line 1513 + 56 bytes nsGenericElement::HandleDOMEvent(nsIPresContext * 0x042255d0, nsEvent * 0x0012f208, nsIDOMEvent * * 0x0012eeec, unsigned int 7, nsEventStatus * 0x0012f568) line 1901 nsHTMLInputElement::HandleDOMEvent(nsIPresContext * 0x042255d0, nsEvent * 0x0012f208, nsIDOMEvent * * 0x00000000, unsigned int 1, nsEventStatus * 0x0012f568) line 1496 + 31 bytes PresShell::HandleEventInternal(nsEvent * 0x0012f208, nsIView * 0x00000000, unsigned int 1, nsEventStatus * 0x0012f568) line 6111 + 41 bytes PresShell::HandleEventWithTarget(PresShell * const 0x05dd48e0, nsEvent * 0x0012f208, nsIFrame * 0x05f3ba0c, nsIContent * 0x05d5a088, unsigned int 1, nsEventStatus * 0x0012f568) line 6068 + 22 bytes nsEventStateManager::CheckForAndDispatchClick(nsIPresContext * 0x042255d0, nsMouseEvent * 0x0012f784, nsEventStatus * 0x0012f568) line 2836 + 66 bytes nsEventStateManager::PostHandleEvent(nsEventStateManager * const 0x03ff7738, nsIPresContext * 0x042255d0, nsEvent * 0x0012f784, nsIFrame * 0x05f3ba0c, nsEventStatus * 0x0012f568, nsIView * 0x28593978) line 1847 + 23 bytes PresShell::HandleEventInternal(nsEvent * 0x0012f784, nsIView * 0x28593978, unsigned int 1, nsEventStatus * 0x0012f568) line 6163 + 49 bytes PresShell::HandleEvent(PresShell * const 0x05dd48fc, nsIView * 0x28593978, nsGUIEvent * 0x0012f784, nsEventStatus * 0x0012f568, int 0, int & 1) line 6006 + 25 bytes nsViewManager::HandleEvent(nsView * 0x0597b4e0, nsGUIEvent * 0x0012f784, int 0) line 2296 nsView::HandleEvent(nsViewManager * 0x2881b630, nsGUIEvent * 0x0012f784, int 0) line 298 nsViewManager::DispatchEvent(nsViewManager * const 0x2881b630, nsGUIEvent * 0x0012f784, nsEventStatus * 0x0012f678) line 2033 + 23 bytes HandleEvent(nsGUIEvent * 0x0012f784) line 79 nsWindow::DispatchEvent(nsWindow * const 0x05ee0d8c, nsGUIEvent * 0x0012f784, nsEventStatus & nsEventStatus_eIgnore) line 1048 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f784) line 1069 nsWindow::DispatchMouseEvent(unsigned int 301, unsigned int 0, nsPoint * 0x00000000) line 5191 + 21 bytes ChildWindow::DispatchMouseEvent(unsigned int 301, unsigned int 0, nsPoint * 0x00000000) line 5446 nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 1114126, long * 0x0012fc30) line 3985 + 28 bytes nsWindow::WindowProc(HWND__ * 0x00130468, unsigned int 514, unsigned int 0, long 1114126) line 1330 + 27 bytes USER32! 77e2a2b8() USER32! 77e045b1() USER32! 77e0a752() nsAppShellService::Run(nsAppShellService * const 0x0195d0b8) line 484 main1(int 1, char * * 0x00262638, nsISupports * 0x01919020) line 1291 + 32 bytes main(int 1, char * * 0x00262638) line 1678 + 37 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77e9847c() Removing "stackwanted" - 3 are enough, right?

See also bug 260140.

Testcase WFM using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060531 Minefield/3.0a1 ID:2006053106 [cairo]

laas, i don`t crash on this testcase with Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9a9pre) Gecko/2007092305 Minefield/3.0a9pre ID:2007092305 Do you still crash with latest Nightly Build ?

Hi, Carsten! I can confirm that latest nightly Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007092405 Minefield/3.0a9pre does not crash with this test case. Yet, current stable, that I'm using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 still crashes. Seems that Minefield has this bug fixed. Best, Laas

wfm based on comments in the bug