Closed Bug 523625 Opened 10 years ago Closed 3 years ago
Disabling JEP/Java doesn't "stick" when another copy of JEP is in /Library/Internet Plug-Ins/
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.
Assignee: nobody → smichaud
Status: NEW → ASSIGNED
The case where JEP is installed separately is too rare to block on.
Flags: blocking1.9.2? → blocking1.9.2-
(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 on attachment 407646 [details] [diff] [review] Fix Oops, this patch dies on Linux. New patch shortly.
Here's a Mac tryserver build made with my rev1 patch: https://firstname.lastname@example.org/bugzilla523625-rev1-macosx.dmg
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.
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/
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.