49247 - Plugins don't get destroyed correctly when in frameset

Status: RESOLVED DUPLICATE of bug 54725

(Core :: Layout, defect, P3)

Description

[edburns]

Reproducible: Always

Steps:

1. build the tip with MOZ_DEBUG=1
2. Install the java plugin (talk to Frank Petita or Rafael Ebron if you're a 
netscape employee to get it)
3. visit the above URL
4. Visit another page.

The Java plugin should begin to spew exceptions.

Normally, when the browser leaves a page with plugins nsObjectFrame::Destroy() 
gets called before the window is destroyed (that is, the WM_DESTROY message is 
sent to the plugin window).  This MUST be the case for the JavaPlugin from Sun 
to NOT HANG THE BROWSER.  All appears well most of the time. 

However when the browser visits a frameset with three frames, and different 
applets in two of them, nsObjectFrame::Destroy() isn't called until after 
WM_DESTROY is sent to the plugin.  Here's the stack trace when WM_DESTROY is 
sent to the plugin (more text after the stack trace):


nsWindow::Destroy(nsWindow * const 0x049af384) line 1131
nsView::~nsView() line 166
nsView::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsView::Destroy(nsView * const 0x049af4c0) line 264 + 34 bytes
nsFrame::Destroy(nsFrame * const 0x0fd81250, nsIPresContext * 0x048360c0) line 
424
nsFrameList::DestroyFrames(nsIPresContext * 0x048360c0) line 36
nsContainerFrame::Destroy(nsContainerFrame * const 0x0fd811d8, nsIPresContext * 
0x048360c0) line 98
nsFrameList::DestroyFrames(nsIPresContext * 0x048360c0) line 36
nsContainerFrame::Destroy(nsContainerFrame * const 0x0fd810dc, nsIPresContext * 
0x048360c0) line 98
nsLineBox::DeleteLineList(nsIPresContext * 0x048360c0, nsLineBox * 0x0fd81188) 
line 252
nsBlockFrame::Destroy(nsBlockFrame * const 0x0fd81054, nsIPresContext * 
0x048360c0) line 1213 + 16 bytes
nsFrameList::DestroyFrames(nsIPresContext * 0x048360c0) line 36
nsContainerFrame::Destroy(nsContainerFrame * const 0x0fd8101c, nsIPresContext * 
0x048360c0) line 98
nsFrameList::DestroyFrames(nsIPresContext * 0x048360c0) line 36
nsContainerFrame::Destroy(nsContainerFrame * const 0x0fd80fe0, nsIPresContext * 
0x048360c0) line 98
ViewportFrame::Destroy(ViewportFrame * const 0x0fd80fe0, nsIPresContext * 
0x048360c0) line 144
FrameManager::~FrameManager() line 383
FrameManager::`scalar deleting destructor'(unsigned int 1) + 15 bytes
FrameManager::Release(FrameManager * const 0x04860b40) line 362 + 157 bytes
PresShell::~PresShell() line 1125 + 27 bytes
PresShell::`scalar deleting destructor'() + 15 bytes
PresShell::Release(PresShell * const 0x04861430) line 1041 + 158 bytes
nsCOMPtr<nsIPresShell>::~nsCOMPtr<nsIPresShell>() line 490
DocumentViewerImpl::~DocumentViewerImpl() line 439 + 97 bytes
DocumentViewerImpl::`scalar deleting destructor'(unsigned int 1) + 15 bytes
DocumentViewerImpl::Release(DocumentViewerImpl * const 0x0498ef30) line 348 + 
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::SetupNewViewer(nsDocShell * const 0x047fba00, nsIContentViewer * 
0x075fb960) line 2663
nsWebShell::SetupNewViewer(nsWebShell * const 0x047fba00, nsIContentViewer * 
0x075fb960) line 386 + 13 bytes
nsDocShell::Embed(nsDocShell * const 0x047fba20, nsIContentViewer * 0x075fb960, 
const char * 0x01dbdf24, nsISupports * 0x00000000) line 2380 + 23 bytes
nsWebShell::Embed(nsWebShell * const 0x047fba20, nsIContentViewer * 0x075fb960, 
const char * 0x01dbdf24, nsISupports * 0x00000000) line 419
nsDocShell::CreateContentViewer(nsDocShell * const 0x047fba00, const char * 
0x0012f8c0, nsIChannel * 0x075a6cd0, nsIStreamListener * * 0x0012f914) line 
2548 + 32 bytes
nsDSURIContentListener::DoContent(nsDSURIContentListener * const 0x047f87e0, 
const char * 0x0012f8c0, int 0, const char * 0x100a1088 gCommonEmptyBuffer, 
nsIChannel * 0x075a6cd0, nsIStreamListener * * 0x0012f914, int * 0x0012f8a4) 
line 100 + 33 bytes
nsDocumentOpenInfo::DispatchContent(nsIChannel * 0x075a6cd0, nsISupports * 
0x00000000) line 359 + 109 bytes
nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x075a8b90, 
nsIChannel * 0x075a6cd0, nsISupports * 0x00000000) line 233 + 16 bytes
nsHTTPFinalListener::OnStartRequest(nsHTTPFinalListener * const 0x075aafc0, 
nsIChannel * 0x075a6cd0, nsISupports * 0x00000000) line 1155
InterceptStreamListener::OnStartRequest(InterceptStreamListener * const 
0x075f34c0, nsIChannel * 0x075a6cd0, nsISupports * 0x00000000) line 1168
nsHTTPServerListener::FinishedResponseHeaders() line 1080 + 48 bytes
nsHTTPServerListener::OnDataAvailable(nsHTTPServerListener * const 0x075f0740, 
nsIChannel * 0x054243e4, nsISupports * 0x075a6cd0, nsIInputStream * 0x075f33ec, 
unsigned int 0, unsigned int 0) line 424 + 8 bytes
nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x075f1250) 
line 400 + 47 bytes
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x075f6a70) line 97 + 12 bytes
PL_HandleEvent(PLEvent * 0x075f6a70) line 587 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x013f8450) line 528 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00f508f8, unsigned int 49525, unsigned int 0, 
long 20939856) line 1043 + 9 bytes
USER32! 77e71250()
013f8450()

This causes the plugin's wndproc to get the WM_DESTROY message IMMEDIATELY:

CJavaPluginView::PluginWndProc(HWND__ * 0x0058094c, unsigned int 2, unsigned 
int 0, long 0) line 577
USER32! 77e71ab7()
USER32! 77e71a77()
NTDLL! 77f7624f()

Much later nsObjectFrame::Destroy() is called, which deallocates the plugin.

Comment 1

[Marc Attinasi]

Here is a cool one for you, Andrei.

Comment 2

[edburns]

Will this make it into nsbeta3?  In any case, I'm about to attach a diff of 
java plugin code, for my reference.

Comment 3

[edburns]

Attachment: Workaround on Java Plugin Side.

Comment 4

[edburns]

I'm happy to report that nsObjectFrame::Destroy is getting called when you 
leave this page now.  We still depend on bug 50547, though.

Comment 5

[Chris Petersen]

Marking verified per last comments.

Comment 6

[edburns]

Hi Xiaobin,

It's difficult to test this bug without having a debug build of the JDK so can 
you please call me at 2pm today to discuss how to get yourself a debug build of 
the JDK?

Comment 7

[edburns]

Xiaobin, what's the status on this?

Comment 8

[Xiaobin Lu]

Hi,Ed:
   I visited the URL http://java.sun.com/people/edburns/work/cams.html.Then I 
changed to another page, it is OK and without any exception.  This bug is also 
passed in Raju's testing list.
   However, the shutdown sequence problem is still there and I wish I could do 
something with it with a well built java plug-in.


  

Comment 9

[edburns]

This is a dup of bug 54725.  Reopening.

Comment 10

[edburns]

*** This bug has been marked as a duplicate of 54725 ***

Comment 11

[Boris Zbarsky [:bzbarsky]]

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