558432 - Java checkbox in prefs doesn't work

Status: RESOLVED FIXED

(Camino Graveyard :: Plug-ins, defect)

Description

[Chris Lawson (gone)]

I somehow managed to un-check "Enable Java" in the course of investigating something a while back. I just noticed today that I've never re-checked it, and Java has continued to work fine the entire time.

I haven't had a chance to try this with a fresh profile yet, and I may have a separate copy of the 0.9.7.3 JEP in my /Library/Internet Plug-Ins/ folder, but about:plugins is only reporting the (built-in) 0.9.7.2 version regardless of the state of that checkbox.

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Yeah, Josh removed the pref (over the objections of a lot of folks, like dveditz) in bug 506985.  The only way to disable individual plug-ins now is with some unknown API(?); see also bug 513979.  

The bugs are even cloudier because the removal happened while there was no Java support (before the JEP was restored), so they're talking about situations that never actually existed.

We need to come up with some sort of solution here, though.

Comment 2

[Samuel Sidler (:ss)]

This is one of those things that could keep Camino from shipping a release with a newer version of Gecko. (That is, a regression from a previous release.)

Josh, any pointers for someone wanting to work on this bug?

Comment 3

[Josh Aas]

We are not going to have code specific to Java in Gecko unless we have to. We are working on removing our historic special-casing of it. For the most part we want to consider it to be just another MIME type handler. This is a significant change, there will be some bumps in the road, but it is the right thing to do and it was widely supported.

If you want to implement a pref in Camino that disables Java you'll need to use a mechanism that is not specific to Java. You'll need to disable Java plugins the same way you'd disable any other plugin. You might want to look at what the addons manager does to disable plugins, if that doesn't work let me know.

As for identifying Java plugins, you'll have to figure that out with your own system. You could check for specific plugins (JEP and JavaPlugin2), or grep for "java" in plugin meta-data. You can look at what we used to do to identify Java if you'd like an example.

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #3)
> You'll need to disable Java plugins
> the same way you'd disable any other plugin. You might want to look at what the
> addons manager does to disable plugins, if that doesn't work let me know.

I think the relevant bugs for that were bug 382367 and bug 339056 (the former adding the backend stuff and the latter adding some UI to fx to exercise the former).

On 1.9.0, you can (I think) see how the existing Java prefs were incorporated into the enable/disable backend code: http://mxr.mozilla.org/seamonkey/source/modules/plugin/base/src/nsPluginHostImpl.cpp#1030

In theory we could keep our existing UI and just have it run some code that flips that flag rather than flipping the pref like it used to do.

Comment 5

[Stuart Morgan]

2.1+'ing; given some of the recent security stuff I'm not comfortable shipping a version of Camino where Java can't be disabled.

Comment 6

[Stuart Morgan]

I wonder if we could just provide an implementation of nsIBlocklistService and use our own prefs to back the plugin checks. That would solve the problem Smokey pointed out of us nuking pluginreg.dat and thus destroying any changes we might make through other means.

The interface is dead simple, so this might not be so bad.

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #6)
> I wonder if we could just provide an implementation of nsIBlocklistService

Would that be all or part of bug 387285?

Comment 8

[Stuart Morgan]

Yes, I guess it would. So if it works for this, two birds!

It should be pretty easy to do the skeleton of it from what I saw--along the lines of some of our other component implementations (make a simple class implementing the interface, do the standard registration song and dance). Then doing this bug would just be adding some implementation to give a dynamic answer for Java (and figuring out how to force the state to update when the pref changes).

Comment 9

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #6)
> use our own prefs to back the plugin checks. That would solve the problem
> Smokey pointed out of us nuking pluginreg.dat and thus destroying any changes
> we might make through other means.

We might also be able to use "navigator.plugins.refresh();" on /welcome/ instead of nuking pluginreg.dat; not sure.  http://help.dottoro.com/external/examples/ljfaxadh/refresh_1.htm

Comment 10

[Stuart Morgan]

I can't remember if I already checked to see if that would correctly handle the bad timestamp case.

Comment 11

[Stuart Morgan]

Taking; I can do this through nsIPluginHost if we can find a better way to deal with preventing stale plugin version info. It looks like ReloadPlugins (which is likely what .refresh() calls) is the same as what runs on load though, unfortunately, so that wouldn't fix the timestamp bug.

Otherwise, I'll play more with the blocklist option.

Comment 12

[Stuart Morgan]

Attachment: fix

This does a few things; they were all so closely linked that it seemed to make more sense to write and review them all at once:
- Adds nsIPluginHost-based disabling of Java (fixing this bug).
- Deliberately uses a new pref name and doesn't migrate (bug 625220; disable Java by default).
- Implements the plugin blocklist service (bug 387285). That's part of this bug because I use it to make our plugin prefs robust across our periodic nuking of pluginreg.date
- Adds a new hidden pref people can use to disable specific, arbitrary plugins, because it was so easy to do. Eventually I think we should do real UI for this, but this guarantees 2.1 will ship with a way for power users to disable arbitrary plugins (which is all the rage these days on the internets).

Comment 13

[Stuart Morgan]

I should mention that I have pref listeners on the hidden pref to bridge to nsIPluginHost, and nsIPluginHost notifies all the browser instances of changes, so the behavior we'll get is:
- Turning Java off will immediate kill java instances immediately, even in open pages. Same with adding any plugin to the hidden camino.disable_plugin_names pref
- Turning Java on or enabling a plugin via hidden pref will apply to all new page loads automatically, even in existing windows.

In short: the old annoying bug where Java and/or plugin enabling changes only took effect in new tabs and windows won't be resurfacing.

Comment 14

[Stuart Morgan]

Attachment: Real fix

Helps if I include the new files.

Comment 15

[Stuart Morgan]

Smokey points out that I had a copy paste fail in the license header. Fixed locally.

Comment 16

[Mike Pinkerton (not reading bugmail)]

+  // plugin info is rebuild each plugin's block state is checked, so we use

rebuilt?

+  const char *changedPref = [[[inNotification userInfo]
+      objectForKey:kPrefChangedPrefNameUserInfoKey] UTF8String];

could this ever be NULL?

sr=pink

Comment 17

[Stuart Morgan]

Nope, that key is always set, and the prefs are all UTF-8 so something would have to be *very* wrong for the conversions to fail.

Comment 18

[Stuart Morgan]

Landed as http://hg.mozilla.org/camino/rev/2b6abae1e8c4

Comment 19

[Stuart Morgan]

Attachment: As landed

For posterity, the patch as actually landed.