Closed Bug 474866 Opened 11 years ago Closed 11 years ago

Plugins not instantiated upon second visit to page on Linux


(Core :: Plug-ins, defect, P1, blocker)

1.9.1 Branch





(Reporter: kbrussel, Assigned: jst)



(Keywords: verified1.9.1)


(2 files)

On Linux, upon the second visit to a web page containing a plugin such as a Java applet, the plugin is not being instantiated by the browser. To reproduce:

Get JDK 6u12 from (I used the self-extracting JRE jar file), symlink lib/i386/ into the Firefox plugins directory, and go to . Click the Clock example. Once the page loads and the clock is running, click the back button. Then click the Clock link again. There will be a hole in the page where the applet should be. The Java Plug-In doesn't appear to be receiving an NPP_New call.

This is a blocker for us.
Flags: blocking1.9.1?
Yeah, this is bad. Regression from bug 472439.
Assignee: nobody → jst
Depends on: 472439
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P1
Target Milestone: --- → mozilla1.9.1b3
Attached patch Fix.Splinter Review
This fixes this bug by reverting part of the change that caused this. This makes us leave the peer in the instance while a plugin is cached in the active plugins list in the plugin host, but it makes the code break the reference from the peer to the owner when a plugin is inserted into that list. This fixes the problem in this bug, and does not appear to regress the leak fix that caused this.
Attachment #358527 - Flags: superreview?(bzbarsky)
Attachment #358527 - Flags: review?(joshmoz)
Attachment #358527 - Flags: superreview?(bzbarsky) → superreview+
Comment on attachment 358527 [details] [diff] [review]

Looks ok if we're really completely guaranteed that cast is safe.  Might be worth using a QI here (with some sort of QI-to-CID setup like nsStandardURL uses, say).
We rely on that cast being safe elsewhere already. At least at, so we should be no less safe now. The interfaces for this stuff should probably just go away for 3.2 anyways, so I'd rather not add more to the mess unless it's needed here.
OS: Linux → All
Hardware: x86 → All
Attachment #358527 - Flags: review?(joshmoz) → review+
So this landed this morning but had to be backed out due to tinderbox showing leaks again, even if I didn't see any increase in leaks here locally. I've got a new patch coming that for me now for the first time shows no leaks when running the test content/base/test/test_bug391728.html, so I think the next patch is good to go. The new patch does what bent suggested as an option when fixing the plugin test leaks that caused this, which was to make the nsPluginInstancePeer have a weak reference to its owner.
Attachment #358803 - Flags: superreview?(mrbkap)
Attachment #358803 - Flags: review?(mrbkap)
Comment on attachment 358803 [details] [diff] [review]
Better fix, that really doesn't leak locally.

jst explained what's going on here over IRC to me.
Attachment #358803 - Flags: superreview?(mrbkap)
Attachment #358803 - Flags: superreview+
Attachment #358803 - Flags: review?(mrbkap)
Attachment #358803 - Flags: review+
Pushed as and
Closed: 11 years ago
Keywords: fixed1.9.1
Resolution: --- → FIXED
Depends on: 475646
It looks like this caused bug 475646
Hi Murali, when you do Linux plugin testing on beta 3, can you also verify this bug is fixed at the same time?   Thanks, Tony
Verified as fixed
Verified on the branch and not on trunk
You need to log in before you can comment on or make changes to this bug.