Closed Bug 54725 Opened 24 years ago Closed 22 years ago

Java does not shutdown correctly at exitting Netscape, or switching pages in frameset.

Categories

(Core Graveyard :: Java: OJI, defect, P1)

Product:
Core Graveyard
Component:
Java: OJI
Platform:
x86
Windows 98
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: teruko, Assigned: joe.chou)

References

(
URL
)

Details

(Keywords: crash)

Attachments

(7 files)

cvs diff -u of sub-optimal workaround 1, first iteration.
5.18 KB, patch
Details | Diff | Splinter Review
a solution to shut down the browser with applet.
508 bytes, text/plain
Details
A better solution than Exit(0)
1.92 KB, text/plain
Details
patch for the trunk to fix viewer not exiting
2.27 KB, patch
Details | Diff | Splinter Review
Some change based on Rod's suggestion
2.34 KB, patch
Details | Diff | Splinter Review
"mKeepGoing" is used instead of "mkeepGoing"
2.33 KB, text/plain
Details
Modified patch that still calls PostQuitMessage()
1.63 KB, patch
Details | Diff | Splinter Review 
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.
Keywords: rtm
Re-assigning to module owner.
Assignee: drapeau → edburns
*** 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
Status: NEW → ASSIGNED
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.
Assignee: edburns → xiaobin.lu
Status: ASSIGNED → NEW
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.
Status: NEW → ASSIGNED
Priority: P3 → P1
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.
Summary: Java does not die at exitting Netscape → Java does shutdown correctly at exitting Netscape, or switching pages in frameset.
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 :-)
Whiteboard: rtm+
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).
Keywords: crash
Whiteboard: rtm+ → [rtm need info]
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.
Summary: Java does shutdown correctly at exitting Netscape, or switching pages in frameset. → Java does not shutdown correctly at exitting Netscape, or switching pages in frameset.
   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)
Whiteboard: [rtm need info] → [rtm+]
Taking over this bug, to check the patch in...
Assignee: xiaobin.lu → rpotts
Status: ASSIGNED → NEW
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?
Assignee: rpotts → mscott
PDT marking [rtm++]. This bug is now out of limbo and approved for checkin to
the branch. Please check in ASAP.
Whiteboard: [rtm+] → [rtm++]
This is now fixed on the branch and Rick already checked it into the tip.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
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.
Keywords: vtrunk
fixed on trunk too (20001120).
Status: RESOLVED → VERIFIED
Keywords: vtrunk
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 !!!
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Whiteboard: [rtm++]
The steps to reproduce are the same... just use mfcEmbed instead of
netscape/mozilla.
Assignee: mscott → joe.chou
Status: REOPENED → NEW
qa:pmac
QA Contact: shrir → pmac
*** Bug 122594 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.0
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.
Depends on: 66748
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.
Status: NEW → RESOLVED
Closed: 24 years ago → 22 years ago
Resolution: --- → WORKSFORME
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).
QA Contact: pmac → petersen
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: