User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007091305 Minefield/3.0a8pre In a nightly build if you load a page handled by a plugin, and then hit the reload/refresh button, the new plugin is loaded and NPP_New is called before NPP_Destroy on the old one is called. This uses more resources and is an unfortunate change in behavior. (And it causes some problems for my product in that it has trouble guessing that this is a reload.) This did not happen in Netscape 4.7, Mozilla 1.0, 1.5, Firefox 1.0, or Firefox 2.0. (I assume that this is some sort of lame optimization, but it confuses things and sucks up resources.) Reproducible: Always Steps to Reproduce: 1. Type a URL to a page handled by a plugin and hit return. 2. Hit the reload/refresh button. 3. Notice that it started making the new plugin before the old one was destroyed. Expected Results: NPP_Destroy for the plugin should be called first, then NPP_New for the reload/refreshed page.

Also this ordering needs to be fixed for bug 98641 to still be fully fixable.

This is still true with a current nightly, and it will break some stuff if it is not fixed before the 3.0 release.

I don't see this behavior with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008052814 Minefield/3.0pre. NPP_Destroy gets called first, then NPP_New. William, should this be marked WFM now?

In 3.0 rc3 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 I still see the described problem, I see the following sequence (not all NPP calls are included) when I type a URL to a page handled by my plugin in the location bar, hit return, and then hit the refresh/reload button: NPP_New 21798040 NPP_NewStream 21798040 NPP_New 32546648 NPP_NewStream 32546648 NPP_Destroy 21798040 (The numbers are the NPP value, so you can see the the initial and reload instance.)

I can also see this problem on solaris. I think the patch for bug 347743 caused this problem. As I tried, it maybe the change below. --------------------------------- void nsObjectFrame::Destroy() { NS_ASSERTION(!mInstantiating, "about to crash due to bug 136927"); // we need to finish with the plugin before native window is destroyed // doing this in the destructor is too late. - StopPlugin(); + StopPluginInternal(PR_TRUE); nsObjectFrameSuper::Destroy(); } --------------------------

OK, I can now reproduce this behavior, so I'll confirm the bug.

(In reply to comment #0) [...] > (I assume that this is some sort of lame optimization, but it confuses > things and sucks up resources.) This is not due to some sort of lame optimization, it's due to us delaying plugin destruction until it's guaranteed to be safe to do it (which it often wasn't before this change). I'm not sure there's much we can do about this unfortunately...

Don't think jst meant to reset these flags. Since this is desired behavior (though unfortunate), i don't think there is any way we can block.

Well, if the plugin destruction needs to wait until everything is ready for destruction, then it sounds like the right fix is to delay loading the new page until the old page is fully destroyed, including any plugins. So, this is still something that should be fixed.

A similar case with Adobe Flash Plugin on Mozilla Firefox 3.0.3. On reloading a SWF file, NPP_Destroy of the previous instance is called after the NPP_New of the current instace is already initialized. Is there any workaround for making NPP_New pause till it sense the previous instance's NPP_Destroy has been successfully done with?

For Java applet, this is an issue for legacy_lifecycle mode, which when hosting page unloaded, the applet instance will be kept alive within JVM and be re-started when load the page later. As NPP_New is called before NPP_Destroy, legacy_lifecycle applet cannot be guaranteed to be same instance on reload as there are two instances of plugin at the time. Chrome and IE both have plugin destroyed before new one created on reload.