523625 - Disabling JEP/Java doesn't "stick" when another copy of JEP is in /Library/Internet Plug-Ins/

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect)

Description

[Steven Michaud [:smichaud] (Retired)]

The 1.9.2 branch no longer has a global security.enable_java setting.
So if you want to disable Java, you need to go to Tools : Add-ons and
disable the Java Embedding Plugin.

But if you do this when another copy of the JEP (besides the bundled
one) exists in either /Library/Internet Plug-Ins or ~/Library/Internet
Plug-Ins, the setting doesn't "stick":  If you quit and restart
Namoroka, the JEP (and Java) will once again be enabled.

Namoroka always uses the bundled JEP, even if another copy exists in
/Library/Internet Plug-Ins or ~/Library/Internet Plug-Ins.  But
Namoroka (like all FF versions) also keeps track of "extra" copies of
the JEP in pluginreg.dat.

This bug happens because it's always one of these "extra" copies that
gets marked disabled.  So when you quit Namoroka and restart it (and
it re-reads pluginreg.dat on startup), Namoroka sees that the bundled
JEP isn't disabled.

This bug won't effect anywhere near the majority of users of Namoroka
on OS X -- most of them don't have extra copies of the JEP in either
/Library/Internet Plug-Ins or ~/Library/Internet Plug-Ins.

But whenever I release a new version of the JEP, some people want to
test it before it gets bundled into FF.  I've long recommended that
these people install the "new" JEP to /Library/Internet Plug-Ins and
remove the "old" JEP from the Contents/MacOS/plugins directory of the
distros they want to test with.  Whoever has done this and tries to
disable Java will encounter this bug.

So I consider this a major bug, and think it should block the FF 3.6
release.

I should be able to post a patch for this bug later today.

Comment 1

[Josh Aas]

The case where JEP is installed separately is too rare to block on.

Comment 2

[Steven Michaud [:smichaud] (Retired)]

Attachment: Fix

(From comment #0)

> This bug happens because it's always one of these "extra" copies
> that gets marked disabled.

This turns out not to be true.

The correct entry in pluginreg.dat gets marked disabled (the one
corresponding to the copy of the JEP in the currently running app
bundle's "plugins" directory).

The bug actually happens in RemoveCachedPluginsInfo(), when it's
called from ScanPluginsDirectory() as the latter scans for plugins in
the currently running app's "plugins" directory.
RemoveCachedPluginsInfo() tries to match the newly found plugins up
with settings from the previously existing pluginreg.dat (which has
been read by ReadPluginInfo() into mCachedPlugins).  But since it's
searching by filename (and not by full path), it matches an entry for
one of the "extra" copies of the JEP -- one that hasn't been marked
disabled.

So this bug is (partly) fallout from my patch for bug 513979.

My solution is 1) to call InDefinedExternalPluginsDir() from
ReadPluginInfo(), and use its results to mark entries in
mCachedPlugins that correspond to plugins located in one of the
defined locations for plugins outside of any app bundle's "plugins"
directory.  Then 2) when RemoveCachedPluginsInfo() is called with
byFileName == PR_TRUE, the cached entries for these plugins are
excluded from the search.

A tryserver build of my patch will follow in a few hours.

Comment 3

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 407646 [details] [diff] [review]
Fix

Oops, this patch dies on Linux.  New patch shortly.

Comment 4

[Steven Michaud [:smichaud] (Retired)]

Attachment: Fix rev1 (build on Linux and Windows)

Comment 5

[Steven Michaud [:smichaud] (Retired)]

Here's a Mac tryserver build made with my rev1 patch:
https://build.mozilla.org/tryserver-builds/[e-mail]-bugzilla523625-rev1/bugzilla523625-rev1-macosx.dmg

Comment 6

[Josh Aas]

Comment on attachment 407655 [details] [diff] [review]
Fix rev1 (build on Linux and Windows)

This patch doesn't apply any more. Do we really want it any more? I'm not convinced that this is important enough for a 1.9.2 update, this situation is pretty uncommon.

Comment 7

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

I'm marking this bug as WONTFIX per bug #1269807.

For more information see - https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/