Closed
Bug 392125
Opened 16 years ago
Closed 16 years ago
Java plugin doesn't stay disabled on restart when disabled via plugin manager
Categories
(Core Graveyard :: Plug-ins, defect)
Core Graveyard
Plug-ins
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.9alpha8
People
(Reporter: tchung, Assigned: mwu)
References
Details
Attachments
(1 file, 2 obsolete files)
11.12 KB,
patch
|
Details | Diff | Splinter Review |
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.
Comment 1•16 years ago
|
||
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
![]() |
||
Comment 2•16 years ago
|
||
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
Assignee | ||
Comment 3•16 years ago
|
||
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 | ||
Updated•16 years ago
|
Assignee: nobody → flamingice
Assignee | ||
Updated•16 years ago
|
Flags: blocking1.9?
Assignee | ||
Comment 4•16 years ago
|
||
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 5•16 years ago
|
||
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+
Assignee | ||
Comment 6•16 years ago
|
||
(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.
Assignee | ||
Comment 9•16 years ago
|
||
Attachment #278164 -
Attachment is obsolete: true
Assignee | ||
Comment 10•16 years ago
|
||
Opps.. uploaded the wrong patch.
Attachment #278905 -
Attachment is obsolete: true
Assignee | ||
Updated•16 years ago
|
Attachment #278907 -
Flags: approval1.9?
Updated•16 years ago
|
Flags: blocking1.9? → blocking1.9+
Assignee | ||
Updated•16 years ago
|
Attachment #278907 -
Flags: approval1.9?
Assignee | ||
Comment 11•16 years ago
|
||
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
Updated•16 years ago
|
Flags: in-litmus?
Reporter | ||
Comment 12•16 years ago
|
||
Added Litmus testcase: http://litmus.mozilla.org/show_test.cgi?id=4618
Flags: in-litmus? → in-litmus+
Reporter | ||
Comment 13•16 years ago
|
||
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
Updated•9 months ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•