On plugin page reload, NPP_New called before NPP_Destroy

RESOLVED WONTFIX

Status

()

Core
Plug-ins
RESOLVED WONTFIX
11 years ago
6 years ago

People

(Reporter: William Bardwell, Assigned: jst)

Tracking

({regression})

Trunk
regression
Points:
---
Bug Flags:
blocking1.9.1 -
wanted1.9.1 +
blocking1.9 -
blocking1.9.0.1 -

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 years ago
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.
(Reporter)

Comment 1

11 years ago
Also this ordering needs to be fixed for bug 98641 to still be fully fixable.
(Reporter)

Comment 2

11 years ago
This is still true with a current nightly, and it will break some stuff if it is not fixed before the 3.0 release.
Blocks: 98641

Comment 3

10 years ago
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?
(Reporter)

Comment 4

10 years ago
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.)
Flags: blocking1.9?

Comment 5

10 years ago
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();
 }
--------------------------

Comment 6

10 years ago
OK, I can now reproduce this behavior, so I'll confirm the bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9?
Flags: blocking1.9.1?
Flags: blocking1.9.0.1?
Flags: blocking1.9-
OS: Windows XP → All
Hardware: PC → All
Assignee: nobody → jst
Flags: wanted1.9.1+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Flags: blocking1.9.0.1?
Flags: blocking1.9.0.1-
Keywords: regression
Priority: -- → P2
(Assignee)

Comment 7

10 years ago
(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...
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Flags: blocking1.9.0.1?
Flags: blocking1.9.0.1-
Priority: P2 → --
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.
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Flags: blocking1.9.0.1?
Flags: blocking1.9.0.1-
(Reporter)

Comment 9

10 years ago
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.
Version: unspecified → Trunk

Comment 10

10 years ago
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?

Comment 11

7 years ago
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.

Updated

6 years ago
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.