Where does FF get the location of the JRE from?
I use Ubuntu Linux 12.04 and FireFox 20. The addons tab indicated that my java plugin had security issues and was currently blocked. Instructions from Mozilla said to change the Java version, which I did. The old one was 1.7.0.15 and the new one is 1.7.0.17 (aka 7u15 and 7u17 respectively). Being a programmer, I'm using the SDK and have my $JAVA_HOME set to the JRE in the SDK. I then changed the symbolic links in /usr/lib/mozilla/plugins and in /usr/lib/firefox/plugins to point to the new version of libnpjp2.so in my updated JRE. Finally I restarted FireFox... But the addons still show the old plugin!
So where is Firefox looking for the the plugin? Is there a config file that I'm not aware of?
منتخب شدہ حل
Thanks for the tip Jscher2000. I checked the full path and noted that the plugin does indeed come from /usr/lib/mozilla/plugins. So obviously there was something wrong with the plugin.
On the basis of the update links supplied by the Mozilla site, I downloaded the lates Java JRE separately to its own directory. I then set the symbolic link in /usr/lib/mozilla/plugins to point to that version of the plugin... <path_to_jre>/lib/i386/libnpjp2.so
That fixed it.
For the benefit of other Linux users: The Java SDK 1.7.0.17 for Linux contains the old version of libnpjp2.so (i.e. 1.7.0.15). Goodness only knows why. Since it is a shared library, it should be OK to simply replace the file with one from the JRE download for version 1.7.0.17.
اس جواب کو سیاق و سباق میں پڑھیں 👍 0تمام جوابات (4)
On Windows, it's the Registry, but on Linux, I do not know.
Perhaps if you knew the location of the plugins Firefox is loading that would provide some insight? To see the full paths to your plugins on the about:plugins page, you can temporarily change a preference in about:config. Please see this post for more information: https://support.mozilla.org/en-US/que.../947530#answer-399436.
منتخب شدہ حل
Thanks for the tip Jscher2000. I checked the full path and noted that the plugin does indeed come from /usr/lib/mozilla/plugins. So obviously there was something wrong with the plugin.
On the basis of the update links supplied by the Mozilla site, I downloaded the lates Java JRE separately to its own directory. I then set the symbolic link in /usr/lib/mozilla/plugins to point to that version of the plugin... <path_to_jre>/lib/i386/libnpjp2.so
That fixed it.
For the benefit of other Linux users: The Java SDK 1.7.0.17 for Linux contains the old version of libnpjp2.so (i.e. 1.7.0.15). Goodness only knows why. Since it is a shared library, it should be OK to simply replace the file with one from the JRE download for version 1.7.0.17.
Try to delete the pluginreg.dat file in the Firefox Profile Folder and maybe addons.sqlite as well to reset the plugin registry databases.
Note that is is usually easier to use a symlink to the folder where the latest Java version is installed.
- /usr/java/latest/lib/i386/libnpjp2.so
You can set the plugin.expose_full_path pref to true on the about:config page to see the full path of enabled installed plugins on the about:plugins page.
- http://kb.mozillazine.org/Issues_related_to_plugins#Identifying_installed_plugins
- http://kb.mozillazine.org/about:plugins
- http://kb.mozillazine.org/about:config
It is best not to leave that pref set to true as it exposes that full path to web servers via the navigator.plugins object, so reset that pref to false after you are done with the about:plugins page.
See "Manually uninstalling a plugin":
Hi cor-el,
The location you mentioned for the latest Java is apparently not used by Ubuntu. It doesn't exist on my version (12.04 LTS). I've had a bit of a hunt around, but nothing seems to fit the bill. I'll try asking on the Ubunut Forums if such a thing exists for Ubuntu.
Deleing the pluginreg.dat was, thankfully; not necessary. When I set the symbolic link to the new plug-in, the browser accepted it and shows the expected version (i.e.1.7.0_17). I can only assume the one in the SDK is wrong. Bit bizarre, really.
... and, yes, I did toggle the plugin.expose_full_path pref back to false.