When you exit Netscape after you visit java page, Java plug-in is still alive. Then, if you want to launch Netscape again, it won't launch. Steps of reproduce 1. Launch Netscape 2. Go to Java page 3. Select File|Exit 4. Try to launch Netscape again Netscape will not launch. On the right side of Window taskbar, the Java icon is there. To launch Netscape again, you need to kill the netscape process. Tested 2000-09-29-09 MN6 Win32 build.

I am unable to reproduce this on today's windows branch build 2000092908

I could reproduce this with build 2000093008 m18 build. However, this happens only if I quit the browser using the 'x' button the top right of the browser window. Quitting the browser via 'File|Exit' does not show this problem.

Nominating this for RTM.

Re-assigning to module owner.

*** Bug 55461 has been marked as a duplicate of this bug. ***

Comments from Stanley Ho. On Windows 95/98/NT4/2000, starting PR3 will work okay the first time. However, after trying to exit the browser using the "X" button at the top right corner, all browser windows are closed, but the browser process remains in memory. When the users try to restart the browser again, the browser will never show up because it is stuck to communicate with the ghost deading process. This bug is pretty bad because I can reproduce it 100% of the time, and normal user won't know what's going wrong other than PR3 is not starting up after first use. However, this bug does not appear when closing the browser through the File- >Close menu. I suspect that the proper browser shutdown sequence is not called when the browser is closed using the "X" button.

a

Pressing the "X" with an applet running results in the WM_DESTROY message being sent to the Plugin before nsObjectFrame::Destroy() is called, like this: CJavaPluginView::PluginWndProc(HWND__ * 0x002207e6, unsigned int 2, unsigned int 0, long 0) line 656 USER32! 77e71ab7() USER32! 77e71a77() NTDLL! 77f7624f() nsView::~nsView() line 165 nsView::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsView::Destroy(nsView * const 0x10b78240) line 263 + 34 bytes nsFrame::Destroy(nsFrame * const 0x013c1330, nsIPresContext * 0x1018b5d0) line 425 nsFrameList::DestroyFrames(nsIPresContext * 0x1018b5d0) line 36 nsContainerFrame::Destroy(nsContainerFrame * const 0x0146f1fc, nsIPresContext * 0x1018b5d0) line 98 nsFrameList::DestroyFrames(nsIPresContext * 0x1018b5d0) line 36 nsContainerFrame::Destroy(nsContainerFrame * const 0x0126faa0, nsIPresContext * 0x1018b5d0) line 98 nsBoxFrame::Destroy(nsBoxFrame * const 0x0126faa0, nsIPresContext * 0x1018b5d0) line 1002 + 13 bytes nsFrameList::DestroyFrames(nsIPresContext * 0x1018b5d0) line 36 nsContainerFrame::Destroy(nsContainerFrame * const 0x0126fa10, nsIPresContext * 0x1018b5d0) line 98 nsBoxFrame::Destroy(nsBoxFrame * const 0x0126fa10, nsIPresContext * 0x1018b5d0) line 1002 + 13 bytes nsFrameList::DestroyFrames(nsIPresContext * 0x1018b5d0) line 36 nsContainerFrame::Destroy(nsContainerFrame * const 0x0126f54c, nsIPresContext * 0x1018b5d0) line 98 nsBoxFrame::Destroy(nsBoxFrame * const 0x0126f54c, nsIPresContext * 0x1018b5d0) line 1002 + 13 bytes nsFrameList::DestroyFrames(nsIPresContext * 0x1018b5d0) line 36 nsContainerFrame::Destroy(nsContainerFrame * const 0x0126eef4, nsIPresContext * 0x1018b5d0) line 98 nsBoxFrame::Destroy(nsBoxFrame * const 0x0126eef4, nsIPresContext * 0x1018b5d0) line 1002 + 13 bytes nsFrameList::DestroyFrames(nsIPresContext * 0x1018b5d0) line 36 nsContainerFrame::Destroy(nsContainerFrame * const 0x0126ee64, nsIPresContext * 0x1018b5d0) line 98 nsBoxFrame::Destroy(nsBoxFrame * const 0x0126ee64, nsIPresContext * 0x1018b5d0) line 1002 + 13 bytes nsFrameList::DestroyFrames(nsIPresContext * 0x1018b5d0) line 36 nsContainerFrame::Destroy(nsContainerFrame * const 0x0126ee28, nsIPresContext * 0x1018b5d0) line 98 ViewportFrame::Destroy(ViewportFrame * const 0x0126ee28, nsIPresContext * 0x1018b5d0) line 144 FrameManager::~FrameManager() line 405 FrameManager::`scalar deleting destructor'(unsigned int 1) + 15 bytes FrameManager::Release(FrameManager * const 0x101b3e30) line 384 + 157 bytes PresShell::~PresShell() line 1272 + 27 bytes PresShell::`scalar deleting destructor'() + 15 bytes PresShell::Release(PresShell * const 0x101b2710) line 1188 + 158 bytes nsCOMPtr<nsIPresShell>::~nsCOMPtr<nsIPresShell>() line 490 DocumentViewerImpl::~DocumentViewerImpl() line 447 + 97 bytes DocumentViewerImpl::`scalar deleting destructor'(unsigned int 1) + 15 bytes DocumentViewerImpl::Release(DocumentViewerImpl * const 0x101884b0) line 355 + 154 bytes nsCOMPtr<nsIContentViewer>::assign_assuming_AddRef(nsIContentViewer * 0x00000000) line 472 nsCOMPtr<nsIContentViewer>::assign_with_AddRef(nsISupports * 0x00000000) line 849 nsCOMPtr<nsIContentViewer>::operator=(nsIContentViewer * 0x00000000) line 584 nsDocShell::Destroy(nsDocShell * const 0x01fcd304) line 1595 nsWebShell::Destroy(nsWebShell * const 0x01fcd304) line 1393 nsXULWindow::Destroy(nsXULWindow * const 0x01fcd864) line 324 nsWebShellWindow::Destroy(nsWebShellWindow * const 0x01fcd864) line 1779 nsWebShellWindow::Close(nsWebShellWindow * const 0x01fcd8c0) line 368 nsWebShellWindow::HandleEvent(nsGUIEvent * 0x0012f63c) line 447 nsWindow::DispatchEvent(nsWindow * const 0x01fcd674, nsGUIEvent * 0x0012f63c, nsEventStatus & nsEventStatus_eIgnore) line 681 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f63c) line 702 nsWindow::DispatchStandardEvent(unsigned int 101) line 722 + 15 bytes nsWindow::ProcessMessage(unsigned int 16, unsigned int 0, long 0, long * 0x0012f974) line 2795 nsWindow::WindowProc(HWND__ * 0x0020074a, unsigned int 16, unsigned int 0, long 0) line 950 + 27 bytes USER32! 77e71ab7() USER32! 77e71a77() NTDLL! 77f7624f() USER32! 77e71310() nsWindow::DefaultWindowProc(HWND__ * 0x0020074a, unsigned int 274, unsigned int 61536, long 3801924) line 977 USER32! 77e7288d() USER32! 77e72918() nsWindow::WindowProc(HWND__ * 0x0020074a, unsigned int 274, unsigned int 61536, long 3801924) line 957 + 31 bytes USER32! 77e71ab7() USER32! 77e71a77() NTDLL! 77f7624f() USER32! 77e71310() nsWindow::DefaultWindowProc(HWND__ * 0x0020074a, unsigned int 161, unsigned int 20, long 3801924) line 977 USER32! 77e7288d() USER32! 77e72918() nsWindow::WindowProc(HWND__ * 0x0020074a, unsigned int 161, unsigned int 20, long 3801924) line 957 + 31 bytes USER32! 77e71250() 003a0344() However, doing File->Exit causes nsObjectFrame::Destroy() to be called before the plugin gets WM_DESTROY. This is CORRECT BEHAVIOR. nsObjectFrame::Destroy(nsObjectFrame * const 0x013c11e0, nsIPresContext * 0x10fa8e90) line 332 nsLineBox::DeleteLineList(nsIPresContext * 0x10fa8e90, nsLineBox * 0x013c1a38) line 252 nsBlockFrame::Destroy(nsBlockFrame * const 0x013bbed4, nsIPresContext * 0x10fa8e90) line 1230 + 16 bytes nsLineBox::DeleteLineList(nsIPresContext * 0x10fa8e90, nsLineBox * 0x013bbf20) line 252 nsBlockFrame::Destroy(nsBlockFrame * const 0x013bbe4c, nsIPresContext * 0x10fa8e90) line 1230 + 16 bytes nsFrameList::DestroyFrames(nsIPresContext * 0x10fa8e90) line 36 nsContainerFrame::Destroy(nsContainerFrame * const 0x013bafd4, nsIPresContext * 0x10fa8e90) line 98 nsFrameList::DestroyFrames(nsIPresContext * 0x10fa8e90) line 36 nsContainerFrame::Destroy(nsContainerFrame * const 0x013bb0b4, nsIPresContext * 0x10fa8e90) line 98 nsBoxFrame::Destroy(nsBoxFrame * const 0x013bb0b4, nsIPresContext * 0x10fa8e90) line 1002 + 13 bytes nsFrameList::DestroyFrames(nsIPresContext * 0x10fa8e90) line 36 nsContainerFrame::Destroy(nsContainerFrame * const 0x013bb010, nsIPresContext * 0x10fa8e90) line 98 nsBoxFrame::Destroy(nsBoxFrame * const 0x013bb010, nsIPresContext * 0x10fa8e90) line 1002 + 13 bytes nsGfxScrollFrame::Destroy(nsGfxScrollFrame * const 0x013bb010, nsIPresContext * 0x10fa8e90) line 486 nsFrameList::DestroyFrames(nsIPresContext * 0x10fa8e90) line 36 nsContainerFrame::Destroy(nsContainerFrame * const 0x013baf98, nsIPresContext * 0x10fa8e90) line 98 ViewportFrame::Destroy(ViewportFrame * const 0x013baf98, nsIPresContext * 0x10fa8e90) line 144 FrameManager::~FrameManager() line 405 FrameManager::`scalar deleting destructor'(unsigned int 1) + 15 bytes FrameManager::Release(FrameManager * const 0x10b9a9d0) line 384 + 157 bytes PresShell::~PresShell() line 1272 + 27 bytes PresShell::`scalar deleting destructor'() + 15 bytes PresShell::Release(PresShell * const 0x10b9c270) line 1188 + 158 bytes nsCOMPtr<nsIPresShell>::~nsCOMPtr<nsIPresShell>() line 490 DocumentViewerImpl::~DocumentViewerImpl() line 447 + 97 bytes DocumentViewerImpl::`scalar deleting destructor'(unsigned int 1) + 15 bytes DocumentViewerImpl::Release(DocumentViewerImpl * const 0x10fb9210) line 355 + 154 bytes nsCOMPtr<nsIContentViewer>::assign_assuming_AddRef(nsIContentViewer * 0x00000000) line 472 nsCOMPtr<nsIContentViewer>::assign_with_AddRef(nsISupports * 0x00000000) line 849 nsCOMPtr<nsIContentViewer>::operator=(nsIContentViewer * 0x00000000) line 584 nsDocShell::Destroy(nsDocShell * const 0x10b70984) line 1595 nsWebShell::Destroy(nsWebShell * const 0x10b70984) line 1393 nsDocShell::DestroyChildren(nsDocShell * const 0x01fcd2f0) line 160 nsDocShell::Destroy(nsDocShell * const 0x01fcd304) line 1597 nsWebShell::Destroy(nsWebShell * const 0x01fcd304) line 1393 nsXULWindow::Destroy(nsXULWindow * const 0x01fcd864) line 324 nsWebShellWindow::Destroy(nsWebShellWindow * const 0x01fcd864) line 1779 nsChromeTreeOwner::Destroy(nsChromeTreeOwner * const 0x01fcef84) line 217 GlobalWindowImpl::Close(GlobalWindowImpl * const 0x1018c5c4) line 2054 nsAppShellService::Quit(nsAppShellService * const 0x00b0fe40) line 446 XPTC_InvokeByIndex(nsISupports * 0x00b0fe40, unsigned int 6, unsigned int 0, nsXPTCVariant * 0x0012dda0) line 139 nsXPCWrappedNativeClass::CallWrappedMethod(JSContext * 0x1018c3a0, nsXPCWrappedNative * 0x109dbac0, const XPCNativeMemberDescriptor * 0x109dced0, nsXPCWrappedNativeClass::CallMode CALL_METHOD, unsigned int 0, long * 0x0131cff0, long * 0x0012df54) line 913 + 43 bytes WrappedNative_CallMethod(JSContext * 0x1018c3a0, JSObject * 0x012ebe20, unsigned int 0, long * 0x0131cff0, long * 0x0012df54) line 228 + 34 bytes js_Invoke(JSContext * 0x1018c3a0, unsigned int 0, unsigned int 0) line 820 + 23 bytes js_Interpret(JSContext * 0x1018c3a0, long * 0x0012ea88) line 2621 + 15 bytes js_Invoke(JSContext * 0x1018c3a0, unsigned int 1, unsigned int 2) line 837 + 13 bytes js_InternalInvoke(JSContext * 0x1018c3a0, JSObject * 0x012ebb38, long 19839808, unsigned int 0, unsigned int 1, long * 0x0012ec20, long * 0x0012ebb0) line 909 + 20 bytes JS_CallFunctionValue(JSContext * 0x1018c3a0, JSObject * 0x012ebb38, long 19839808, unsigned int 1, long * 0x0012ec20, long * 0x0012ebb0) line 3193 + 31 bytes nsJSContext::CallEventHandler(nsJSContext * const 0x1018c550, void * 0x012ebb38, void * 0x012ebb40, unsigned int 1, void * 0x0012ec20, int * 0x0012ec1c, int 0) line 907 + 33 bytes nsJSEventListener::HandleEvent(nsIDOMEvent * 0x10fc7624) line 154 + 64 bytes nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x1095c9d0, nsIDOMEvent * 0x10fc7624, nsIDOMEventTarget * 0x10186e48, unsigned int 8, unsigned int 7) line 788 + 19 bytes nsEventListenerManager::HandleEvent(nsIPresContext * 0x1018c930, nsEvent * 0x0012f494, nsIDOMEvent * * 0x0012f41c, nsIDOMEventTarget * 0x10186e48, unsigned int 7, nsEventStatus * 0x0012f4dc) line 1670 + 39 bytes nsXULElement::HandleDOMEvent(nsXULElement * const 0x10186e40, nsIPresContext * 0x1018c930, nsEvent * 0x0012f494, nsIDOMEvent * * 0x0012f41c, unsigned int 1, nsEventStatus * 0x0012f4dc) line 3321 PresShell::HandleDOMEventWithTarget(PresShell * const 0x101b27b0, nsIContent * 0x10186e40, nsEvent * 0x0012f494, nsEventStatus * 0x0012f4dc) line 4302 + 39 bytes nsMenuFrame::Execute() line 1495 nsMenuFrame::HandleEvent(nsMenuFrame * const 0x012db154, nsIPresContext * 0x1018c930, nsGUIEvent * 0x0012f8c8, nsEventStatus * 0x0012f7b8) line 378 PresShell::HandleEventInternal(nsEvent * 0x0012f8c8, nsIView * 0x10e2fc90, unsigned int 1, nsEventStatus * 0x0012f7b8) line 4270 + 38 bytes PresShell::HandleEvent(PresShell * const 0x101b27b4, nsIView * 0x10e2fc90, nsGUIEvent * 0x0012f8c8, nsEventStatus * 0x0012f7b8, int 0, int & 1) line 4190 + 25 bytes nsView::HandleEvent(nsView * const 0x10e2fc90, nsGUIEvent * 0x0012f8c8, unsigned int 8, nsEventStatus * 0x0012f7b8, int 0, int & 1) line 379 nsView::HandleEvent(nsView * const 0x10ed18b0, nsGUIEvent * 0x0012f8c8, unsigned int 8, nsEventStatus * 0x0012f7b8, int 0, int & 1) line 352 nsView::HandleEvent(nsView * const 0x10fa6350, nsGUIEvent * 0x0012f8c8, unsigned int 8, nsEventStatus * 0x0012f7b8, int 0, int & 1) line 352 nsView::HandleEvent(nsView * const 0x101b2e40, nsGUIEvent * 0x0012f8c8, unsigned int 28, nsEventStatus * 0x0012f7b8, int 1, int & 1) line 352 nsViewManager2::DispatchEvent(nsViewManager2 * const 0x101b1040, nsGUIEvent * 0x0012f8c8, nsEventStatus * 0x0012f7b8) line 1439 HandleEvent(nsGUIEvent * 0x0012f8c8) line 68 nsWindow::DispatchEvent(nsWindow * const 0x101b2d04, nsGUIEvent * 0x0012f8c8, nsEventStatus & nsEventStatus_eIgnore) line 681 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f8c8) line 702 nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 3890 + 21 bytes ChildWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 4100 nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 18481204, long * 0x0012fc44) line 2960 + 24 bytes nsWindow::WindowProc(HWND__ * 0x003806e0, unsigned int 514, unsigned int 0, long 18481204) line 950 + 27 bytes

Xiaobin, can you please mark the bug assigned to you for this issue as a DUPLICATE of this bug?

*** Bug 54369 has been marked as a duplicate of this bug. ***

This bug was assigned to me by Ed.

I am now trying to compare the difference between the File->Exit and "x" from browser. "File->Exit" definitely works fine, so we think there must somthing missing of "x". I will try to fix it as soon as possible.

Moving to P1. This bug will prevent the user from re-stating the browser if they close the browser while visiting the page with an applet.

Ed, I think for multiple window case, the browser works well. So, if we can find the number of windows is equal to 1, in WM_CLOSE, we can use PostQuitMessage(0).

* This method is a workaround for bug 54725. * This bug is nsObjectFrame::Destroy() is called "too late" when the * user closes the window by using the "X" in the title bar. "Too late" * means "the system sends the plugin WM_DESTROY *before* * nsObjectFrame::Destroy() is called". This bug does not occurr when * the user closes the browser by using File->Exit. * This workaround is to cause all currently running plugins to be * destroyed when a window is closed. This is heavy handed, but will * prevent a crash, and possible "ghost" process, the latter of which * will prevent the user from re-starting the browser without explicitly * killing the process. * Here is one possible scenario that will be problematic to the user, * but will, with this fix, not crash the browser: * The user has two browser windows running. Both with plugins. The * user uses the "X" to close one of the windows. This workaround will * destroy the all the plugins running in the browser. The user will * then have to reload the remaining window's page to see the plugin in * that page again.

Ed, is it possible at the point of WM_DESTROY processing to check if we have additional Navigator windows, and if so skip KillPlugins?

I tried to close the browser using "x" and "File->close"(Not "File->Exit). When I use "x" to close the browser, the CJavaPluginView::Destroy happens before the nsObjectFrame::Destroy and it stuck in a window system call(The stack trace is listed below). When I close the browser using "File->Close", nsObjectFrame::Destroy is called before CJavaPluginView::Destroy and it stucks at AWT_Toolkit::MessageLoop. When I exit the browser with an applet running using "x" button, the stack trace which makes the browser can not be shutdown is listed below: ----------------------------------------------------------------------------- 1.nsWindow::ProcessMessage(unsigned int 16, unsigned int 0, long 0, long * 0x0012f854) line 2802 2.nsWindow::WindowProc(HWND__ * 0x00640270, unsigned int 16, unsigned int 0, long 0) line 955 + 27 bytes 3.USER32! 77e148dc() 4.USER32! 77e163fb() 5.USER32! 77e1643d() 6.NTDLL! 77f9f04b() 7.USER32! 77e15b59() 8.USER32! 77e148dc() 9.USER32! 77e17ef9() 10.USER32! 77e17f75() 11.nsWindow::WindowProc(HWND__ * 0x00640270, unsigned int 274, unsigned int 61536, long 3736388) line 962 + 31 bytes 12.USER32! 77e148dc() 13.USER32! 77e163fb() 14.USER32! 77e1643d() 15.NTDLL! 77f9f04b() 16.USER32! 77e15b59() 17.USER32! 77e148dc() 18.USER32! 77e17ef9() 19.USER32! 77e17f75() 20.nsWindow::WindowProc(HWND__ * 0x00640270, unsigned int 161, unsigned int 20, long 3736388) line 962 + 31 bytes 21.USER32! 77e148dc() 22.USER32! 77e14aa7() 23.USER32! 77e266fd() 24.nsAppShellService::Run(nsAppShellService * const 0x00d19960) line 408 25.main1(int 1, char * * 0x00497788, nsISupports * 0x00000000) line 1004 + 32 bytes 26.main(int 1, char * * 0x00497788) line 1185 + 37 bytes 27.mainCRTStartup() line 338 + 17 bytes 28.KERNEL32! 77e992a6() -------------------------------------------------------------------------------- I added the line numbers to make my explaination easier. The process stucks at line 5 which is a window system call (CallWindowProc, I think). So, I modified the code in nsWindow.cpp(widget/src/windows). In function nsWindow::WindProc. if (nsnull != someWindow) { LRESULT retValue; //****This is the code I added if(msg==161 && wParam==20){ msg=16; wParam=0; lParam=0; } //****End of modification******** if (PR_TRUE == someWindow->ProcessMessage(msg, wParam, lParam, &retValue)) { return retValue; } } #if defined(STRICT) return ::CallWindowProc((WNDPROC)someWindow->GetPrevWindowProc(), hWnd, msg, wParam, lParam); #else return ::CallWindowProc((FARPROC)someWindow->GetPrevWindowProc(), hWnd, msg, wParam, lParam); #endif } Now when I traced the code, I can get rid of that window system call.But I still can not shut down the browser. And finally, it stucks at the AWT_TOOLKIT::MessageLoop. I think what we can do to fix this bug is to modified the CJavaPluginView::Destroy to get out of the message loop of AWT_Toolkit.

*** Bug 54340 has been marked as a duplicate of this bug. ***

The second attachment posted above actually replace the PostQuitMessage(0) with an exit(0) and the effect is to force the application exit. We thought that is not a good way to solve this bug. A better way is applied in the third attchment which essentially use a flag to exit the application. Using PostQuitMessage(0) actually generates a WM_QUIT message which is finally passed into the nsAppShell::Run and hopefully it will exit the message loop. Normally it works well. However for some reasons which currently is unclear to me, "WM_QUIT" message could not be passed into the run method. Looking into the code, I found that it used a flag called "keepGoing" which is generated by comparing msg==WM_QUIT. So instead of wasting time to compare with the message which could not be guaranteed to passed into, just setting keepGoing=0 to notify that the application would like to exit. This change needs to modify the nsAppShell and add the keepGoing as a data member. Any suggestions to this fix?

I have tested this out and it works as advertised, I am not sure about the issue with WM_QUIT though. So the fix looks good except for some clean up, keepGoing should be mKeepGoing and be a PRBool instead of int. Also, PR_TRUE/PR_FALSE should be used. With this fix, viewer on no longer exits. The following patch fixes the viewer exiting problem.

Rod, does your attachment 17644 [details] [diff] [review] fix only work for viewer? Xiaobin: I have confirmed that the fix in the 10/17/00 attachment works. I think we should petition to get this fix into the branch, not the trunk. Xiaobin: can you send mail to brendan@mozilla.org and tell him about this fix? We should, at the very least, try to get your 10/17/00 fix into the branch. This is low risk and high gain. If we get another fix, we can remove this one.

My patch should be applied in addition to "attachment (id=17623)" patch. To summerize: Patch 17623 will fix mozilla and cause viewer hang on exit, my patch (17644) when applied after 17623, will fix viewer so it no longer hangs on exit. This work was all tested on the trunk, but I see no reason why it won't work the same for the branch. Plus, viewer needs to exit properly even on branch for regression testing.

Patch looks good to me, get an r= and get it into the trunk at least. Thanks, /be

In keeping with the file's coding style it should be mKeepGoing (instead of mkeepGoing) and I say it is good to go. r=rods

Taking a quick glance at the patch it occurs to me that we should make sure that this patch does not introduce additional leaks on shutdown. The patch effectively short-circuits the processing of any events left pending in the message queue. Some of those events may be PLEvents which may be necessary to destroy the PresShell or other objects.

Kevin: Thanks for your suggestion! The fix of this bug only affects the final shutdown which means only one top window left based on my understanding. After the browser is shutdown, all the memory resources is reclaimed by the kernel. Anyway, if using PostQuitMessage(0) still can not guarantee that all the resouces will be reclaimed.

" After the browser is shutdown, all the memory resources is reclaimed by the kernel." Unfortunately, this is not always true. On WIN95 and WIN98 we will consume GDI resources if we shutdown without releasing them.

Because the quit message was inserted at the end of the message queue, all of the existing messages in the msg queue would be processed before the quit message. After the quit message there should not be an additional messages in the msg queue.

Can I change the status of this bug to fixed?

*** Bug 49247 has been marked as a duplicate of this bug. ***

A bug cannot be marked as fixed until the code is checked in. In this case into the trunk and the branch.

What is the status of this bug? Which fix should be put in the tree?

I'm not the best super-reviewer for this, it's too Windows-y. I liked what I saw last time, and it sounds like kmcclusk has proved that GDI resoures won't be leaked (?). I nominate rpotts for super-review, if he's willing. Rick, how about it? I will owe you the same in return! /be

Personally, I'd have a "warmer and fuzzier" feeling if we called PostQuitMessage() *and* set mKeepGoing=PR_FALSE in nsAppShell::Exit() I don't think that there should be any adverse effects by calling PostQuitMessage()... -- rick PS. I'm adding danm to the CC list, in case he has some insights :-)

Rick: The net effect of PostQuitMessage(0) is to generate a WM_QUIT message. But when we visit a webpage with an applet, this message is not handled very well. We are not very clear at this time why it doesn't work like this. But at least if we set mKeepGoing=PR_FALSE when the browser is shut down, the nsAppShell::Run can respond to that change very well and exit the browser right away. Actually the nsAppShell also used a flag "keepGoing" which is generated by comparing message with WM_QUIT. And we actually know when this WM_QUIT message will be generated, so instead of using PostQuitMessage(0) in nsAppShell::Quit(), using a flag to mark the application end is not a bad way. Thanks very much for your suggestion!

I've done some digging and it looks like this patch is really a band-aid which masks the real problem - the java plugin is not shutting down correctly because its window is destroyed before nsObjectFrame::Destroy() is called... In particular, this patch does not work in the embedded case - where mozilla does not own the message pump. My guess is that nsPluginInstanceOwner should be destroying the plugin when its native window gets destroyed... Right now, the plugin is only destroyed when nsObjectFrame::Destroy() is called.

I have not confirmed that GDI resources will not leak with this patch. We need to run with and with/out the patch and look at the output from bloaty. If any additional leaks result, this is a cause for concern, because in many cases this will result in GDI resource leaks. I agree with rpotts accessment. The plugin should shutdown properly without short-circuiting the message loop.

After digging on this problem, I found that it is a window multithreading problem. "Basically, Microsoft window programmers were advised that a message-queue thread spend no more than 1/10 second processing any message. Anything that take longer should be done in a different thread."(Adapted from Charles Petzold,"Programming Windows 95" Page 741, line 15). To prove that it is such a problem, I did an experiment. Add Sleep(1000) before PostQuitMessage(0)(The file is in /widget/sc/windows/nsAppShell.cpp, nsAppShell::Exit).Go to a webpage with an applet running, the browser is well shutdown. Decreasing the sleep time until 10 millisencond, the browser is shutdown well. However, if I continue decreasing the sleep time, the bug appears. Another experiment has some relationship with different applets. Go to <http://www.toptips.com>, there is an applet running there, no problem shutting down the browser( I mean, the application exits well). However, visiting a webpage <http://java.sun.com>will make the user feel embarassed. Because that webpage has two applets and it needs JavaPlugin Thread to take a long time(more than 1/10 seconds) to clean. So, it defeated the "1/10 second rule". I strongly guess that is not the problem of java plugin shutdown, except it may take more than 1/10 seconds to complete, because JavaPlugin Shutdown thread did not destroy the WM_QUIT message which is generated by PostQuitMessage(0).I have tested that WM_QUIT is correctly generated and it is put in the message queue of the main thread. So, if the nsAppShell::Run can detect that message (using PeekMessage), it should exit. However, after Java Plugin Thread did a long time clean, the PeekMessage can not detect there is a WM_QUIT message there, so it can not exit the application. Kevin: Would you like to test that patch using a flag to exit the application? I think this bug took us too long time. Your work will be greatly appreciated! Xiaobin

I tried using the patch on a branch build from yesterday. It crashes shortly after the profilemanager goes away. Without the patch it works fine. If I bring up Mozilla and avoid the profile manager I can't get a full bloaty log on exit because of some bad RDF XML. Without the patch I get a full bloat log. I think we are leaking additional objects with the patch installed so we are running across a problem dumping the additional objects. In addition, In the past, I have seen stack-traces where the presshell is destroyed as the result of PLEvent being processed, so short-circuiting the message processing would definitly cause GDI leaks in these cases.

After some discussions, it looks like the Java plug-in is entering its own message loop when it is shutting down... Unfortunately, it is removing the WM_QUIT message from the event queue and ignoring it :-( So, when we fall back into nsAppShell::Run(), rather than getting the WM_QUIT message, we fall into WaitMessage() and hang forever :-( I'm attaching a slightly different patch, which I think is less risky. Basically, the patch still calls PostQuitMessage(), but it also sets a global flag indicating that PostQuitMessage was called. Then, in nsAppShell::Run, if the global flag is set and no messages are in the message queue (ie. someone ate WM_QUIT), rather than doing a WaitMessage() and hanging the App, we exit the run loop as if WM_QUIT had been received... The advantage of this patch is twofold: 1. In the case where the Java Plugin is not present, PostQuitMessage() is still the mechanism which terminates the process. 2. If the WM_QUIT message is consumed by "someone else", all pending events in the event queue are *still* processed before nsAppShell::Run() returns. THis should insure that all PLEvents etc, have been dispatched and no leaks should occur... How does this sound? -- rick

Marking rtm+ I need some reviewers and an sr for this one :-)

It is important to remember that this is just a band-aid fix. It will not fix the shutdown hang when mozilla is embedded !! Until the Java Plug-in is fixed to *not* eat the WM_QUIT message of the application, embedded applications of mozilla will (most likely) hang on shutdown if Java is active. -- rick

As described by Rick, when this bug strikes, N 6 hangs during the shutdown, and you can't start up N6 again :-(. The fix seems very consrained in breadth, and should go into a limbo list for inclusion if time permits. The first thing is to get the set of sr and a= reviews. When you have them, please mark the bug [rtm+] so we can get it onto the limbo list RSN. Rick: After getting the reviews, can you land this on the trunk ASAP and see if there are any regressions? I'm putting in the "crash" keyword because the user perception (when the app won't re-start) is that attempts to re-start simply "crash" (i.e., you click, and the app tries to start... and then gives up). I could try "hang" or something, but the inability to start is at least as severe as any crash problems (including crash on startup).

You'd be crazy not to fix this bug before launch. Java applets are often used in banner ad placements. There's a common scratch-it lotto applet that I've seen on many different web sites. All of these sites will stop Netscape from ever running again until the user reboots the computer. The behavior before they reboot is especially confusing, since double clicking on the icon does absolutely nothing. The user won't even be aware that Java was somehow involved. Perhaps the bug should be renamed 'Netscape 6 never runs again for no apparent reason' to express the severity of it.

By the help of your guys, especially Rick, we have found that the "real" reason of this bug is JavaPlugin calls AtlWaitWithMessageLoop(HANDLE hEvent) during shutdown. The code is: ATLINLINE ATLAPI_(BOOL) AtlWaitWithMessageLoop(HANDLE hEvent) { DWORD dwRet; MSG msg; while(1) { dwRet = MsgWaitForMultipleObjects(1, &hEvent, FALSE, INFINITE, QS_ALLINPUT); if (dwRet == WAIT_OBJECT_0) return TRUE; // The event was signaled if (dwRet != WAIT_OBJECT_0 + 1) break; // Something else happened // There is one or more window message available. Dispatch them while(PeekMessage(&msg,NULL,NULL,NULL,PM_REMOVE)) { TranslateMessage(&msg); DispatchMessage(&msg); if (WaitForSingleObject(hEvent, 0) == WAIT_OBJECT_0) return TRUE; // Event is now signaled. } } return FALSE; } In this code, it calls PeekMessage(&msg,NULL,NULL,NULL,PM_REMOVE) and it will remove the WM_QUIT message from the message queue of the main thread. So, the main message loop(/widget/src/windows/nsAppShell.cpp) will not see this message and as a result it will not shut down the browser. Based on Rick's suggestion, instead of calling AtlWaitWithMessageLoop(HANDLE hEvent), we can just call WaitForSingleObject(). Although it will lock up the UI, at this point the browser is shutting down anyway. I added a method in "XAtlWaitWithMessageLoop(HANDLE hEvent)" in natives.cpp files( plugin/oji-plugin/src/win32/core/). //-----Workaround of bug 54725---------------------------- ATLINLINE ATLAPI_(BOOL) XAtlWaitWithMessageLoop(HANDLE hEvent) { DWORD dwRet; MSG msg; while(1) { dwRet = MsgWaitForMultipleObjects(1, &hEvent, FALSE, INFINITE, QS_ALLINPUT); if (dwRet == WAIT_OBJECT_0) return TRUE; // The event was signaled if (dwRet != WAIT_OBJECT_0 + 1) break; // Something else happened if (WaitForSingleObject(hEvent, 0) == WAIT_OBJECT_0) return TRUE; // Event is now signaled. } return FALSE; } /* * Class: sun_plugin_navig_win32_PluginFrame * Method: waitEvent * Signature: (I)V */ JNIEXPORT void JNICALL Java_sun_plugin_navig_win32_PluginFrame_waitEvent (JNIEnv *env, jobject is, int handle) { #ifndef DEBUG TRACE2("Waiting event %d\n", handle); __try { #endif HANDLE waitingEvent = reinterpret_cast<HANDLE>(handle); XAtlWaitWithMessageLoop(waitingEvent); #ifndef DEBUG } __except(EXCEPTION_EXECUTE_HANDLER) { } #endif } I tested this kind of solution and it can shutdown the browser well. Unfortunately, we won't have a Java plug-in with the fix until next spring time. We would like to use Rick's patch (PostQuitMessage and falg to shutdown) as a temporary fix to this server bug. Rick: Thanks very much for your patch! Xiaobin

I reviewed rpotts modified patch and it looks good. I ran viewer and mozilla with the patch installed on the branch. Both exit normally. r=kmcclusk@netscape.com

rpotts: I don't mind the int 0/1 boolean usage, especially since it makes your patch minimal. sr=brendan@mozilla.org for branch and trunk. We should have a bug open to remove this workaround next Spring, or whenever it is possible to force users who care to upgrade to the new Java plugin. /be

marking rtm+ since the patch has been reviewed and approved. Rick, you should check this into the trunk asap. Also, you might want to produce a new branch version of the patch patch without all the additional comments, to show PDT how small this patch really is (the comments seem to be about half of the changes) (By the way, there's a typo in `reeceived...' in a comment in your patch)

Taking over this bug, to check the patch in...

This bug is in candidate limbo. We will reconsider this fix once we have a candidate in hand, but we can't take this fix before then. I'm also handing this bug off to mscott, as Rick asked that he handle the branch checkin. Since this is going into the RTM limbo, we really like this landed on the trunk asap, to watch for any/all regressions. Who will handle the trunk landing? Rick: Can you do this trunk checkin?

PDT marking [rtm++]. This bug is now out of limbo and approved for checkin to the branch. Please check in ASAP.

This is now fixed on the branch and Rick already checked it into the tip.

I've checked the patch into the trunk... -- rick

This works fine for me on NT, but then again, it worked fine without the fix as well...

This is fixed in windows branch build 2000-10-31-14-MN6. Adding keyword: vtrunk for trunk verification.

fixed on trunk too (20001120).

I'm reopening this bug because JRE 1.4.0-beta3 still causes mfcEmbed to hang on shutdown!! Mozilla works because the hack to its message pump is present :-( This *really* needs to be fixed within the java plugin !!!

The steps to reproduce are the same... just use mfcEmbed instead of netscape/mozilla.

qa:pmac

*** Bug 122594 has been marked as a duplicate of this bug. ***

This bug is back. JRE 1.3 and JRE 1.4. Tested to exist on W98 and W2k in Build 2002041711 (RC1). Easy reproduce. Just visit java.sun.com and let the page finish loading. Click X to exit Mozilla. Try to relaunch any browser window. Reproduces every time. I'm voting for this bug. This is a really nasty one. Users will not tolerate a browser that refuses to launch for no apparent reason.

In order to completely fix this problem (and a host of other java bugs) we must: a) Make sure that the plugin's window is destroyed *after* the plugin has been destroyed. See comment #42. This issue is also the crux of bug #66748 b) Prevent the java plugin from dispatching PLEvents from the browser. The java plugin regularly enters the function AtlWaitWithMessageLoop(...) without pushing a new nsEventQueue. This violates mozilla's event dispatching archetecture -- which requires a new EventQueue be pushed whenever a sub-message-pump is entered. For many months now, I have been trying to raise this issue with Sun engineers... Unfortunately I have had NO success in convincing them that is a SERIOUS problem :-( So, at this point, i'm at a bit of a loss... We can fix (a) which will fix one class of java bugs.. But until we can resolve (b) as well, java will continue to behave erratically and be unstable. -- rick

In exploring this bug more I've discovered a couple of tidbits that may be helpful. Some site do now cause Moz/Java to die in memory. http://www.sandrasue2.com will exit properly while http://java.sun.com will not. If you visit a page that has no Java on it after visiting a Java site, the browser will shutdown properly. If you select File > Exit the browser will always shutdown properly (As noted in #2) Between this and Bug 100393 Moz is very nearly a Java incapable browser. ISP et. al. are not going to pickup a browser that needs this much hand holding

Which version of JRE are you guys testing with? Using JRE 1.4.0_01 or 1.4.1(not available yet), I can't reproduce the problem. By the way, 100393 has been fixed in the 1.4.0_01 release which Sun gave to Netscape last week.

I seems to depend on the Java applet that is running. One of the applets at java.sun.com also takes a very long time to initialize. I see the problem with 1.3.1_03 and 1.4.0_1. Problem is shows on W98 and W2K with MOZ 2002041711. Also note when duplicating if you are on a page with no java it will always shut down properly. Just opening the "Java Console" will not duplicate the problem.

Tried the test case (going to a java page, java.sun.com; exit browser by either file->exit or clicked on X; re-launch browser), it seemed working fine with moz099 and JRE 1.4 (recently downloaded from java.sun.com/j2se), on win2000. Reporter, could you try it again, and see what happens? (To setup JRE1.4, simply copy NPOJI140.dll to plugins directory).

Humm, I can't dupe it now either. Same Java, same build: JRE 1.4.0, RC1 2002041711 Maybe there was a problem with the Applet on the Sun page (You'd think that if anybody could get an applet right...) I haven't found any other java pages that will reliably produce this bug.

Tried it again with moz1.0 RC2 and JRE 1.4 on XP, and it seemed also working fine. Marking WORKSFORME.

Rick: do we want Java to push the WM_QUIT message back on to the message queue? ATLINLINE ATLAPI_(BOOL) XAtlWaitWithMessageLoop(HANDLE hEvent) { ... while(PeekMessage(&msg,NULL,NULL,NULL,PM_REMOVE)) { + if(msg.message == WM_QUIT) + { + PostOuitMessage(); + return xxx; + } TranslateMessage(&msg); DispatchMessage(&msg); if (WaitForSingleObject(hEvent, 0) == WAIT_OBJECT_0) return TRUE; // Event is now signaled.

wfm on the browser side, windows 2k, jre 1.4.0_01 (netscape branch build: 200-08-23-10-1.0).