Changing the value of nsPluginInstanceVariable_DoCacheBool or nsPluginInstanceVariable_CallSetWindowAfterDestroyBool will definitely break the Beatnik Player xpcom plugin. It's explicitly setting the value for those 2 when my nsIPluginInstance::GetValue() method is called.
Did we already have those two in NS6 RTM? I just cannot immediately recall...
Yes - these were added Sept 14 2000: http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/modules/plugin/public/nsplugindefs.h
av: Sean's got it; the changes were the result of a meeting amongst Netscape and plugin vendors, to discuss changes in the plugin lifecycle. One problem that I know of is that the Sun Java Plug-In had problems with the existing lifecycle, so we lobbied to change it. We also lobbied to have a flag that a plug-in could set, asking whether to cache a plugin instance; the Java Plug-In wanted control over applet caching, not having the browser control it. Does that ring a bell? If not, lemme know, and I'll happily send you the meeting notes written by Eric Krock.
No, no, George, I remember all this. It just came up recently that there is no uniformity and variable values overlap partially, so some binaries may confuse this DoCache thing with GetJavaClass which may probably not be that important since new plugins shouldn't worry about java class anyway. Also I noticed that some variables belong in wrong places. Which is annoying but not a big issue.
Hm...this explain a lot. If Java is reporting it's cache variable incorrectly then that explain why may patch to crashing in ~nsPluginInstanceOwner on release works for 4.x plugins and Real Player XPCOM but not Java. I will take a closer loook.
peter? any update on this? Any thing I can do to help investigate this? anthonyd
I don't know what can be done about this now. I suggest staying clear of these messed up variables.
leaving in future, we will try to resolve this during general plug-in clean-up
I cleaned up npapi.h vs. nsplugindefs.h discrepancies a while ago, basically by eliminating the latter.