513979 - make sure that if someone had disabled java through preferences in Firefox <= 3.5, it stays disabled in Firefox > 3.5

Status: VERIFIED FIXED

(Firefox :: Settings UI, defect, P2)

Description

[Mike Beltzner [:beltzner, not reading bugmail]]

Bug 506985 removed the preference for disabling Java from the Content prefpane. We need to make sure that anyone who had disabled Java this way ends up with the Java plugin still disabled once they upgrade to Firefox 3.6.

Comment 1

[Josh Aas]

We're fine on Windows and Linux because the pref operated by marking any Java plugins as disabled. When a user upgrades the plugin remains disabled and can be enabled in the Addons Manager.

This is also true on Mac OS X except we also move users to a new Java plugin. So the JEP, which was disabled, is gone and the new Java plugin, JavaPlugin2, is enabled. This is much less of a big deal.

The only possible solution is probably to do a 1-time check of the pref and if Java is disabled then disable JavaPlugin2. I'm not sure it is worth it.

Comment 2

[Nim Delineif]

(In reply to comment #1)
> We're fine on Windows and Linux because the pref operated by marking any Java
> plugins as disabled. When a user upgrades the plugin remains disabled and can
> be enabled in the Addons Manager.

Wrong. I had Java disabled, but it executed an <applet> (Firefox 3.7a1pre on Windows XP).

> The only possible solution is probably to do a 1-time check of the pref and if
> Java is disabled then disable JavaPlugin2. I'm not sure it is worth it.

People will be annoyed when they see Applets executing when they had Java disabled. Then they will turn to Preferences and won't be able to find the checkbox they used to disable it last time.

Preferences should stay in the state the users had it.

Comment 3

[Josh Aas]

(In reply to comment #2)
> Wrong. I had Java disabled, but it executed an <applet> (Firefox 3.7a1pre on
> Windows XP).

I don't see this behavior. There are a bunch of things that might re-enable Java (install a new plugin, wipe out pluginreg.dat) but we can't keep disabling it just because a user used to have that pref set because there is no UI for unsetting it.

Comment 4

[Marcia Knous [:marcia]]

Josh asked me to test the following path and here are my results:

1. Running FF 3.5.3, install the latest version of Java (this lab machine had no Java, hence this step was needed).
2. Confirmed that Java is functional by loading clock demo.
3. Disabled Java by going to Tools -> Options -> Content and unchecking the box.
4. Launched the Firefox 3.6 latest nightly (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a2pre) Gecko/20090910 Namoroka/3.6a2pre (.NET CLR 3.5.30729)) and loaded a Java page.
5. Java was disabled in the clock demo and other sites I visited.

I will note that I was running a side by side install in the above scenario.

Comment 5

[Josh Aas]

Resolving this as WFM as this isn't a problem on any platform.

Comment 6

[Josh Aas]

It was only maybe a problem on Mac given the special case of removing JEP but it isn't clearly a problem there either and we're restoring JEP anyway.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Marcia, I'm not able to get it working with the same steps as you have given in comment 4. As given by Bob Java applets are started on 1.9.2 even when the user has disabled Java on 1.9.1.

Comment 9

[Steven Michaud [:smichaud] (Retired)]

Attachment: 1.9.2 branch patch

I've figured out why this bug happens with the JEP, and not with other
plugins -- in short it's because the JEP is in the distro's plugins
directory.

The patch for bug 506985 removed the security.enable_java setting,
together with supporting code.  Now (on the trunk and 1.9.2 branch)
you should be able to disable or enable Java by disabling or enabling
whichever plugin provides support for the x-java-vm or x-java-applet
mime types.

But Firefox has for some time used the full path to identify each
plugin, and every distro's bundled JEP has a different full path.  So
if you disable the JEP in one distro, that setting doesn't get
preserved when you run another distro that also bundles the JEP.

When you run the second distro, it (in ReadPluginInfo()) reads
pluginreg.dat and loads all those plugins (and their settings) into
the "plugin cache" (nsPluginHost::mCachedPlugins).  Then (in
nsPluginHost::ScanPluginsDirectory()) it scans each "plugins
directory" for plugins, and (in the call to RemoveCachedPluginsInfo())
looks for matches with what was previously in the "plugins cache".  If
it finds a match, the match's settings are carried over.

But if a given distro's RemoveCachedPluginsInfo() always uses the full
path to look for a match, it will never find the settings for another
distro's JEP (or for any plugins that are bundled in the various
distros' plugins directory).

My patch gets around this by making RemoveCachedPluginsInfo() search
by filename (and not by path) whenever ScanPluginsDirectory() is
called on the bundle's plugins directory.

My patch is probably the smallest change we can make to fix this bug.
In principle it would be possible to restore the security.enable_java
setting.  But I don't think that's really necessary.

Tryserver builds will follow eventually.

Windows and Linux also use the distro's plugins directory for some
plugins.  While this patch's change is aimed at fixing a Mac problem,
I think it'd also be desirable on other platforms.  However, if need
be I can ifdef the patch to make it only have effect on the Mac.

Comment 10

[Josh Aas]

Comment on attachment 406068 [details] [diff] [review]
1.9.2 branch patch

+  void RemoveCachedPluginsInfo(const char *fileSpec, PRBool fromAppPluginsDir,

This function doesn't really care why it is searching by filename so please rename "fromAppPluginsDir" to "byFileName" or something like that.

Then, where you check for the app plugin dir, please add a comment explaining why we care about that directory.

Comment 11

[Steven Michaud [:smichaud] (Retired)]

Attachment: 1.9.2-branch patch, rev1 (follow Josh's suggestions)

> if need be I can ifdef the patch to make it only have effect on the
> Mac.

Josh, sounds like you don't think this is necessary.

Comment 12

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 406101 [details] [diff] [review]
1.9.2-branch patch, rev1 (follow Josh's suggestions)

Landed on the 1.9.2 branch:
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/83b06d5debec

This should probably also get onto the trunk, but that's not urgent.

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+2]]

How much do we take care of people who want to downgrade to Firefox 3.5? Having Java disabled when upgrading to 3.6 will make leave it disabled on 3.6. But enabling it again and downgrading to Firefox 3.5 always disables it.

Comment 14

[Justin Dolske [:Dolske]]

I'm not really concerned about that case; we only need to make sure we do the right thing on normal upgrades, and that downgrades don't break things.

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Alright. Further testing doesn't show up any other issues. Verified fixed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b1pre) Gecko/20091014 Namoroka/3.6b1pre ID:20091014033739