97960 - First time, the Netscape feedback app started - subsequently, the entire Mozilla application closes without warning (does not crash, just terminates).

Status: RESOLVED WORKSFORME

(Core :: XUL, defect)

Description

[phil]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.3) Gecko/20010801
BuildID:    2001080110

When visiting the above link, pretend you are going to download the firmware for
Version 1.0d for Windows 2000.  Click "Windows 2000" and a javascript window
will open.  Click "I agree" - this is where the Netscape Feedback window opened
(and all my Mozilla windows closed).  Subsequent visits get to the firmware
download page - where the Mozilla just terminates rather than saving the
download stream.  There is no crash data - the app just terminates suddenly (all
windows close)

Reproducible: Always
Steps to Reproduce:
1. Visit
http://solutionsnetwork.yamaha.com/knowledge/SolutionView.asp?ID=040360239931992&QSOperationID=170368214636012&ResponseID=080360239907322&
2. Click "Windows 200" for version 1.0d.
3. Click the <I Agree> button in the 'Disclaimer and Agreement' dialog box. 
4. Click the 'CRW2200EZ Firmware' link.  Mozilla should die rather than
accepting the download stream.

Actual Results:  Mozilla terminated without warning.  All open Mozilla windows
closed instantly.

Expected Results:  Downloaded the file.  I tested it with IE, which downloads
the file as you would expected (correct behaviour).

Laptop running Windows 2000 - both Mozilla and IE installed.  Fairly clean machine..

Comment 1

[[e-mail] (gone - use [e-mail] instead)]

This does indeed initiate Talkback, my incident ID is TB34827475M (build 20010831)

Comment 2

[Michael Hendy (Hendikins)]

Also happens with N6.1/WinNT (I can't put Moz on this machine to test it with,
but I'd say it's still happening...)

Comment 3

[[e-mail] (gone - use [e-mail] instead)]

Attachment: TB34827475

Comment 4

[Matthias Versen [:Matti]]

BTW: I get the same bad stack with my win32 debug build...

Comment 5

[Vinay Badami]

Attachment: html file that triggers this bub

Attached a html file that triggers this bug. Work with IE.
Running under the debugger, I get the following stack trace.
NTDLL! 77fa018c()
NTDLL! 77fa739b()
NTDLL! 77fb4e73()
NTDLL! 77fa7004()
NTDLL! 77fcba91()
KERNEL32! 77e89a0b()
KERNEL32! 77e89dac()
USER32! 77e36517()
SHELL32! 783046b5()
SHELL32! 78306e6e()
SHELL32! 78306ce3()
SHELL32! 783042f4()
SHELL32! 783052e1()
SHELL32! 7830538a()
COMDLG32! 76b35f24()
COMDLG32! 76b37d3d()
COMDLG32! 76b374bf()
COMDLG32! 76b358db()
USER32! 77e12e98()
USER32! 77e21a8c()
USER32! 77e149b1()
USER32! 77e1d6a1()
USER32! 77e1e202()
USER32! 77e1e4bb()
USER32! 77e38036()
COMDLG32! 76b372c7()
COMDLG32! 76b356a8()
COMDLG32! 76b35290()
COMDLG32! 76b3569a()
XPTC_InvokeByIndex(nsISupports * 0x048a89e0, unsigned int 14, unsigned int 1,
nsXPTCVariant * 0x0012c260) line 106
XPCWrappedNative::CallMethod(XPCCallContext & {...}, XPCWrappedNative::CallMode
CALL_METHOD) line 2009 + 42 bytes
XPC_WN_CallMethod(JSContext * 0x047e6e08, JSObject * 0x04667118, unsigned int
0, long * 0x048a513c, long * 0x0012c508) line 1266 + 14 bytes
js_Invoke(JSContext * 0x047e6e08, unsigned int 0, unsigned int 0) line 832 + 23
bytes
js_Interpret(JSContext * 0x047e6e08, long * 0x0012cdd8) line 2798 + 15 bytes
js_Invoke(JSContext * 0x047e6e08, unsigned int 3, unsigned int 2) line 849 + 13
bytes
nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJSClass * const 0x047a7ad8,
nsXPCWrappedJS * 0x047ed8f0, unsigned short 4, const nsXPTMethodInfo *
0x047a618c, nsXPTCMiniVariant * 0x0012d2d0) line 1216 + 22 bytes
nsXPCWrappedJS::CallMethod(nsXPCWrappedJS * const 0x047ed8f0, unsigned short 4,
const nsXPTMethodInfo * 0x047a618c, nsXPTCMiniVariant * 0x0012d2d0) line 430
PrepareAndDispatch(nsXPTCStubBase * 0x047ed8f0, unsigned int 4, unsigned int *
0x0012d380, unsigned int * 0x0012d370) line 115 + 31 bytes
SharedStub() line 139
nsExternalAppHandler::PromptForSaveToFile(nsILocalFile * * 0x0012d5b8, const
unsigned short * 0x047aef40, const unsigned short * 0x0012d52c) line 1136 + 53
bytes
nsExternalAppHandler::SaveToDisk(nsExternalAppHandler * const 0x0473475c,
nsIFile * 0x00000000, int 0) line 1208 + 67 bytes
XPTC_InvokeByIndex(nsISupports * 0x0473475c, unsigned int 5, unsigned int 2,
nsXPTCVariant * 0x0012d728) line 106
XPCWrappedNative::CallMethod(XPCCallContext & {...}, XPCWrappedNative::CallMode
CALL_METHOD) line 2009 + 42 bytes
XPC_WN_CallMethod(JSContext * 0x047e6e08, JSObject * 0x04666450, unsigned int
2, long * 0x048a50c4, long * 0x0012d9d0) line 1266 + 14 bytes
js_Invoke(JSContext * 0x047e6e08, unsigned int 2, unsigned int 0) line 832 + 23
bytes
js_Interpret(JSContext * 0x047e6e08, long * 0x0012e2a0) line 2798 + 15 bytes
js_Invoke(JSContext * 0x047e6e08, unsigned int 0, unsigned int 0) line 849 + 13
bytes
js_Interpret(JSContext * 0x047e6e08, long * 0x0012eb24) line 2798 + 15 bytes
js_Invoke(JSContext * 0x047e6e08, unsigned int 1, unsigned int 2) line 849 + 13
bytes
js_InternalInvoke(JSContext * 0x047e6e08, JSObject * 0x04666580, long 73819896,
unsigned int 0, unsigned int 1, long * 0x0012ed9c, long * 0x0012ec54) line 924
+ 20 bytes
JS_CallFunctionValue(JSContext * 0x047e6e08, JSObject * 0x04666580, long
73819896, unsigned int 1, long * 0x0012ed9c, long * 0x0012ec54) line 3405 + 31
bytes
nsJSContext::CallEventHandler(nsJSContext * const 0x047e7860, void *
0x04666580, void * 0x046666f8, unsigned int 1, void * 0x0012ed9c, int *
0x0012eda0, int 0) line 1011 + 33 bytes
nsJSEventListener::HandleEvent(nsJSEventListener * const 0x04822bb0,
nsIDOMEvent * 0x0448deb8) line 180 + 77 bytes
nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x04822c90,
nsIDOMEvent * 0x0448deb8, nsIDOMEventTarget * 0x047e7cf0, unsigned int 1,
unsigned int 7) line 1205 + 20 bytes
nsEventListenerManager::HandleEvent(nsEventListenerManager * const 0x048222e0,
nsIPresContext * 0x0482af10, nsEvent * 0x0012f4f0, nsIDOMEvent * * 0x0012f494,
nsIDOMEventTarget * 0x047e7cf0, unsigned int 7, nsEventStatus * 0x0012f518)
line 1878 + 36 bytes
GlobalWindowImpl::HandleDOMEvent(GlobalWindowImpl * const 0x047e7ce0,
nsIPresContext * 0x0482af10, nsEvent * 0x0012f4f0, nsIDOMEvent * * 0x0012f494,
unsigned int 1, nsEventStatus * 0x0012f518) line 636
DocumentViewerImpl::LoadComplete(DocumentViewerImpl * const 0x047c7a58,
unsigned int 0) line 1180 + 47 bytes
nsDocShell::EndPageLoad(nsIWebProgress * 0x047e89e4, nsIChannel * 0x04822658,
unsigned int 0) line 3430
nsWebShell::EndPageLoad(nsIWebProgress * 0x047e89e4, nsIChannel * 0x04822658,
unsigned int 0) line 923
nsDocShell::OnStateChange(nsDocShell * const 0x047e8804, nsIWebProgress *
0x047e89e4, nsIRequest * 0x04822658, int 131088, unsigned int 0) line 3338
nsDocLoaderImpl::FireOnStateChange(nsIWebProgress * 0x047e89e4, nsIRequest *
0x04822658, int 131088, unsigned int 0) line 1110
nsDocLoaderImpl::doStopDocumentLoad(nsIRequest * 0x04822658, unsigned int 0)
line 749
nsDocLoaderImpl::DocLoaderIsEmpty() line 647
nsDocLoaderImpl::OnStopRequest(nsDocLoaderImpl * const 0x047e89d4, nsIRequest *
0x04839ff8, nsISupports * 0x00000000, unsigned int 0) line 578
nsLoadGroup::RemoveRequest(nsLoadGroup * const 0x047e8ab8, nsIRequest *
0x04839ff8, nsISupports * 0x00000000, unsigned int 0) line 525 + 44 bytes
nsJARChannel::OnStopRequest(nsJARChannel * const 0x04839ffc, nsIRequest *
0x0488ce4c, nsISupports * 0x00000000, unsigned int 0) line 618
nsOnStopRequestEvent::HandleEvent() line 213
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x0448ddf4) line 116
PL_HandleEvent(PLEvent * 0x0448ddf4) line 590 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00e55358) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x001f02c2, unsigned int 49525, unsigned int 0,
long 15029080) line 1071 + 9 bytes
USER32! 77e12e98()
USER32! 77e130e0()
USER32! 77e15824()
nsAppShellService::Run(nsAppShellService * const 0x00e62490) line 303
main1(int 1, char * * 0x003c81d0, nsISupports * 0x00000000) line 1264 + 32
bytes
main(int 1, char * * 0x003c81d0) line 1594 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e97d08()

It is not a case of stack overflow since I have tried increasing the stack size
to 4M and it still crashes with the same stack trace.

Comment 6

[Vinay Badami]

I should also add that if I just try to download the exe file, I do not see the
problem. Seems to happen only with the javascript involved. 

Comment 7

[Vinay Badami]

Attachment: purify errors

FMM: Freeing mismatched memory in delete(void *) {6 occurrences}
FMM: Freeing mismatched memory in delete(void *) {6 occurrences}
[E] FIM: Freeing invalid memory in LocalFree {1 occurrence}
[E] FMW: Free memory write in GetCurrentDirectoryW {1 occurrence}
[E] EXU: Unhandled exception in GetSaveFileNameA {1 occurrence}

Comment 8

[Vinay Badami]

50 is the maximum stack depth that purify generates. Dont ask for better. (-:

Comment 9

[Brendan Eich [:brendan]]

Is the purified build mixing debug and non-debug versions of CRT, as the PAR
indicates?  That's just broken, it will lead to heap corruption.

I don't believe the symbols in the backtraces, either.  Lots of repeated
JS_XDRMemDataLeft repetition, and the topmost frames seem to be off in MS COM
land.  Cc'ing dbaron for advice.

/be

Comment 10

[Vinay Badami]

Brendan
this is a normal debug build under w2k.
I did not do any special purified build since purify on windows instruments the
exe/dlls at run time.
So if we are  mixing debug and non-debug versions of CRT, then we are doing so
in the normal debug builds too.
It looks like someone is corrupting the stack. This could happen if a stack
variable overflowed. In such cases, I would very much suspect that the
backtraces are not correct. I say this becuase when i run under the debugger,
sometimes i get a stacktrace with only 
COMDLG32! 76b37e8d()
f70c758b()
which cannot be right. I would have expected to see a lot more functions on the
stack.

Comment 11

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

If you're seeing a corrupted stack it could be useful to step through in the
debugger as you approach the crash and watch the stack window to see when it
disappears.

Comment 12

[neeti]

->vinay (gagan from neeti's desk)

Comment 13

[Nivedita (gone)]

Attachment: Stack Trace

Brenden,
I find the crash occurs because in nsFilePicker::Show, the mWnd (i.e hwndOwner
member of OPENFILENAME struct) has an invalid window reference. 
By making this parameter hwndOwner as NULL (default value), we avoid the crash
and go ahead as usual in saving the file. 

The hwndOwner gets an invalid reference be'cos the reference of the window it
holds is already closed. This happens b'cos when save dialog is coming up on
clicking the link, onblur of the pop up is called. I observed that onblur ends
up in calling close of the pop up window. Hence this pop up window closes. 

The popup does not have a onblur handler defined, hence what would be default
action performed for this event? 

I have attached the stack trace.
The parent window and pop up have js fun call javascript:focus on the onload of
the body. 

Can you please convey your thoughts on above.

Comment 14

[Darin Fisher]

mass move of bugs assigned to vinay to me

Comment 15

[Darin Fisher]

sounds like this needs to be looked at by someone working in widget land...

Comment 16

[John Morrison]

Further to what nivedita said:

> The popup does not have a onblur handler defined, hence what would be 
> default action performed for this event? 

Actually, the popup does have an onblur handler defined. When you click on 
the link in attachment 62835 [details], the server returns a text/html document that,
in brief, looks like this:

<body onblur="javascript:close()"></body>
<script>
  location.href = "blahblahblah.exe";
</script>

So, the popup window closes, and a new document stream starts to come in, which 
should be handled by ... hmmm. 

-> danm, cc: blaker

FWIW, in a current win2k trunk opt. build, I just silently exit the application 
and all open windows (i.e., no crash dialog, etc.)

Comment 17

[Juan José Mata]

Changing target milestone to 'Future' since these seem to have missed the 1.2
alpha.  If you are still considering a fix for 1.2 please re-target accordingly.

Comment 18

[Wayne Mery (:wsmwk)]

url/testcase no longer works.

Comment 19

[Jesse Ruderman on Windows]

The testcase doesn't crash for me.  Since this bug is extremely old and the stack trace doesn't look especially enlightening, I'm marking this bug as WFM.

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20090912 Minefield/3.7a1pre (.NET CLR 3.5.30729)