Closed Bug 392125 Opened 15 years ago Closed 15 years ago

Java plugin doesn't stay disabled on restart when disabled via plugin manager

Categories

(Core Graveyard :: Plug-ins, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.9alpha8

People

(Reporter: tchung, Assigned: mwu)

References

Details

Attachments

(1 file, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a8pre) Gecko/2007081304 Minefield/3.0a8pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a8pre) Gecko/2007081304 Minefield/3.0a8pre

I am unable to disable the java embedded plugin using the plugin manager.  I've "disabled" the component and restarted, but it still appears as enabled.  Also, the java applet in the URL example will be reset to enable after a browser restart.

Reproducible: Always

Steps to Reproduce:
1. install latest minefield
2. install JEP plugin
3. open Tools > Addons > plugins
4. Disable JEP, then restart browser
5. Go to URL testsite, and verify java applet still loads
6. go back to plugin manager, and verify JEP is still enabled after reboot.
Actual Results:  
Java applet still loads after disabling and restarting.

Expected Results:  
java applet should be disabled after restart.
I've confirmed this with today's nightly on both Mac OS X and Windows
XP -- so it's clearly not a bug in the Java Embedding Plugin.  (On
Windows XP I disabled all the "Java(TM) 2 Platform Standard Edition
5.0" plugins -- they were all enabled again after I restarted
Minefield.)

Disabling the Java Embedding Plugin via Tools : Addons : Plugins
_does_ work as long as you _don't_ restart Minefield.

I suppose Minefield is confused because previously the only way to
disable or enable Java was via Preferences : Enable Java.
Summary: Java Embedded Plugin does not disable via plugin manager → Java plugin doesn't stay disabled on restart when disabled via plugin manager
This is known... the preferred route is for a decision to be made in regards to bug 344638 before we can fix this.
Depends on: 344638
Moving.. fix belongs in backend plugins code
Component: Extension/Theme Manager → Plug-ins
Product: Firefox → Core
QA Contact: extension.manager → plugins
Target Milestone: --- → mozilla1.9 M8
Version: unspecified → Trunk
Assignee: nobody → flamingice
Flags: blocking1.9?
Attached patch Special case Java plugins (obsolete) — Splinter Review
This does two things:

1. Whether a plugin is a java plugin is now checked once at java tag initialization, as opposed to as needed.
2. Disabling java plugins now flips the java enable/disable pref first, which then causes the plugin host code to iterate through all java plugins and actually toggle their enabled/disabled state.
Attachment #278164 - Flags: superreview?(jst)
Attachment #278164 - Flags: review?(jst)
Comment on attachment 278164 [details] [diff] [review]
Special case Java plugins

- In nsPluginTag::nsPluginTag():

+      if (nsPluginHostImpl::IsJavaMIMEType(mMimeTypeArray[i]))
+        mIsJavaPlugin = PR_TRUE;

This is conditionally set to PR_TRUE here, but it's never defaulted to false anywhere in this constructor. This will lead to random plugins thinking they're java plugins.

r+sr=jst with that fixed.
Attachment #278164 - Flags: superreview?(jst)
Attachment #278164 - Flags: superreview+
Attachment #278164 - Flags: review?(jst)
Attachment #278164 - Flags: review+
(In reply to comment #5)
> (From update of attachment 278164 [details] [diff] [review])
> - In nsPluginTag::nsPluginTag():
> 
> +      if (nsPluginHostImpl::IsJavaMIMEType(mMimeTypeArray[i]))
> +        mIsJavaPlugin = PR_TRUE;
> 
> This is conditionally set to PR_TRUE here, but it's never defaulted to false
> anywhere in this constructor. This will lead to random plugins thinking they're
> java plugins.
> 
Ick, I did it in the other constructor but not this one. Opps. Thanks.
Duplicate of this bug: 393869
Duplicate of this bug: 394163
Attached patch Special case Java plugins, v2 (obsolete) — Splinter Review
Attachment #278164 - Attachment is obsolete: true
Opps.. uploaded the wrong patch.
Attachment #278905 - Attachment is obsolete: true
Attachment #278907 - Flags: approval1.9?
Flags: blocking1.9? → blocking1.9+
Attachment #278907 - Flags: approval1.9?
Checking in modules/plugin/base/src/nsPluginHostImpl.cpp;
/cvsroot/mozilla/modules/plugin/base/src/nsPluginHostImpl.cpp,v  <--  nsPluginHostImpl.cpp
new revision: 1.589; previous revision: 1.588
done
Checking in modules/plugin/base/src/nsPluginHostImpl.h;
/cvsroot/mozilla/modules/plugin/base/src/nsPluginHostImpl.h,v  <--  nsPluginHostImpl.h
new revision: 1.109; previous revision: 1.108
done
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Added Litmus testcase: http://litmus.mozilla.org/show_test.cgi?id=4618
Flags: in-litmus? → in-litmus+
Verified fix on Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a8pre) Gecko/2007090504 Minefield/3.0a8pre.  JEP remains disabled now if selected.
Status: RESOLVED → VERIFIED
Depends on: 398313
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.