Closed Bug 392125 Opened 16 years ago Closed 16 years ago
Java plugin doesn't stay disabled on restart when disabled via plugin manager
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
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.
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.
(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.
Opps.. uploaded the wrong patch.
Attachment #278905 - Attachment is obsolete: true
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: 16 years ago
Resolution: --- → FIXED
16 years ago
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
You need to log in before you can comment on or make changes to this bug.