Closed
Bug 392125
Opened 18 years ago
Closed 18 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•18 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•18 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•18 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•18 years ago
|
Assignee: nobody → flamingice
| Assignee | ||
Updated•18 years ago
|
Flags: blocking1.9?
| Assignee | ||
Comment 4•18 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•18 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•18 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•18 years ago
|
||
Attachment #278164 -
Attachment is obsolete: true
| Assignee | ||
Comment 10•18 years ago
|
||
Opps.. uploaded the wrong patch.
Attachment #278905 -
Attachment is obsolete: true
| Assignee | ||
Updated•18 years ago
|
Attachment #278907 -
Flags: approval1.9?
Updated•18 years ago
|
Flags: blocking1.9? → blocking1.9+
| Assignee | ||
Updated•18 years ago
|
Attachment #278907 -
Flags: approval1.9?
| Assignee | ||
Comment 11•18 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: 18 years ago
Resolution: --- → FIXED
Updated•18 years ago
|
Flags: in-litmus?
| Reporter | ||
Comment 12•18 years ago
|
||
Added Litmus testcase: http://litmus.mozilla.org/show_test.cgi?id=4618
Flags: in-litmus? → in-litmus+
| Reporter | ||
Comment 13•18 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•3 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•