62788 - Mac plugin window and child controls destroyed prematurely

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect, P3)

Description

[Nicholas Hart]

When embedding a plugin on the Mac the plugin's window (and subsequently all of 
its children) are disposed of by Netscape *before* either SetWindow() or Stop() 
are called.

This is, IMHO, bad behavior because not only is it causing the RealPlayer 
plugin to crash, but the plugin should have a chance to dispose of any controls 
it creates.  The browser should not do it for us.

I would note than in Netscape 4.x we are given a chance to destroy our own 
controls (when NPP_Destroy is called our control handles are still valid.)

I have patched CloseWindow, DisposeControl and KillControls and verified that 
NS6 is indeed destroying these controls for us.  We may be able to figure out a 
workaround/hack to get this working in the near-term.  However, long-term I 
would expect that you would want to change this behavior.

(eg: Stop() the plugin or call SetWindow() with a null window *before* you 
destroy it and its children.)

Comment 1

[Keyser Sose]

Reporter what build are you using? Are you able to reproduce it with the latest
nightlies?

Comment 2

[Nicholas Hart]

Mozilla/5.0 (Macintosh; N; PPC; en-US; m18) Gecko/20001108 Netscape6/6.0

I have not tried this with any nightlies-- we are only testing against the gold 
NS6 release.

Comment 3

[Keyser Sose]

Marking NEW as per Asa's wishes :)

Comment 4

[Peter Lubczynski]

I think one of the patches in bug 68759 may fix this. Marking depend.

Reporter, what do you think?

Comment 5

[Peter Lubczynski]

Can anyone still experiencing this bug please try with a latest nighly from 
mozilla.org. I've also looked through the trunk, and like Brian I see his 
results. Netscape 6 and 6.01 come from a very old branch. 

If it is still happening, please post a stack trace to DisposeWindow. Thanks!

Comment 6

[karnaze (gone)]

Moving to m0.9 and reassigning to peterl.

Comment 7

[Peter Lubczynski]

I set a breakpoint in the destructor of nsMacWindow and it is indeed being 
called BEFORE Destroy() is called on the ObjectFrame. This is what is causing 
::DisposeWindow to be called before SetWindow(). 

The nsMacWindow is getting destroyed first because a NS_XUL_CLOSE event is sent, 
to my guess to the parent(s) because it's not the same address of the one the 
plugin is holding. Perhpas the outer-most nsMacWindow?

But, there is a problem here. Kevin/Chris/Rod feel free to jump in with a 
solution. I put a printf to see if ANY events were getting to the ObjectFrame 
before the window gets destroyed. None are. One idea is to refcount the window 
but I'm not sure how other code would react to that and I'm also not sure WHICH 
window to refcount. Another idea is to re-order the destruction, perhpas 
aborting the first one and sending another NS_XUL_CLOSE after plugins get a 
chance at it. What do you think?

Comment 8

[Peter Lubczynski]

Mark,

Your kungFuDeathGrip hack in bug 67006 may be good to use here.

       case NS_XUL_CLOSE: {
+        // Calling ExecuteCloseHandler may actually close the window
+        // (it probably shouldn't, but you never know what the users JS 
+        // code will do).  Therefore we add a death-grip to the window
+        // for the duration of the close handler.
+        nsCOMPtr<nsIWebShellWindow> kungFuDeathGrip(eventWindow);
         if (!eventWindow->ExecuteCloseHandler())
           eventWindow->Close();
         break;

Comment 9

[Peter Lubczynski]

I'm marking this bug WFM because I verified in the debugger that the CGrafPtr 
that's in nsPluginWindow isn't being destroyed by ::DisposeWindow untill AFTER 
Stop() is called. It is doing the right thing. Please re-open if you don't 
agree.

The GrafPtr(s) being passed into ::DisposeWindow before Stop() are hidden 
windows created for popups.