123124 - Don't download Java plug-in if some other is already installed

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, enhancement)

Description

[Petr Panuska]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; Win 9x 4.90; 
FREESERVE_IE5; Q312461)
BuildID:    2001122106

Most users use more browsers (IE, NN, Mozilla, Opera). NN, Mozilla, Opera uses 
Java plug-in which must be downloaded and installed. For example, Opera needn't 
to download Java plug-in if there does exist some for NN. It is possible to use 
one installation of Java plug-in for all browsers but this possibility isn't 
offered by Mozilla browser. I think, this new feature could help meny people 
not to install a few instations of the same program - Java plug-in. Before 
download of this feature it's better to look if there isn't some installed yet. 
That's all.
Cheers,
  Petr Panuska
More power to Mozilla!!


Reproducible: Always
Steps to Reproduce:
Stupid question - it's not bug, it's ask for new feature.

Comment 1

[Boris Zbarsky [:bzbarsky]]

To plugins.  Don't we already scan for plugins?

Comment 2

[shrirang khanzode]

ah, again. Peter, I think we still have not checked in the 'java scan' code  
thing. Is this that bug's dup ?

Comment 3

[Peter Lubczynski]

No, I don't think the 'scan code' is a good idea anymore because the Sun JRE 1.4
is an XPCOM component that requires a totally differenet installation method.

cc:ing a bunch of people for ideas on how to solve this problem. How can we save
users the trouble of re-downloading the entire JRE for every Gecko-based browser?

Perhaps the browser's installer could "ask" the JRE to re-register itself with
new Gecko based browers?

Comment 4

[Steven Katz]

Ok, let me see if I understand what is being asked for here:

Lets assume that the JRE has been installed on the local machine.  Then someone
installs a gecko based browser.  You want that gecko based browser to be able to
use the JRE that is already installed.

So assuming that the browser can somehow locate the already installed JRE, what
you need is a command to call that will cause the plugin to "do the right thing"
depending on its installation needs.  This command will probably need to take as
an argument the location of the installation of the gecko based browser.  

As of today no exposed interface exists to allow this, but if this meets the
needs of all parties, I will see if we can submit this idea as an RFE.

Comment 5

[Daniel Veditz [:dveditz]]

Are there registry keys the installer can look at? If we can find and tell the
difference between 1.3 and 1.4 the Mozilla installer could do the plugin copying
for one and the regxpcom call for the other.

Comment 6

[Steven Katz]

I assume there are registry keys. 

The Mozilla installer COULD take the steps to install the plugin based on its
determination of version, but I think that would be a mistake (that is it would
only provide a solution for what exists today).  Since it is the plugin (and in
fact each version of the plugin) that knows how it needs to be installed it
should be the responsibility of the plugin (or some part thereof) to see that
that action is carried out (given the approprite information).  

Ultimitly, in order to make life as easy as possible for end users, we will
probably have to have the Mozilla installer handle the actual process of
connection to the browsers for JRE's 1.4 and earlier and ask later JRE to do
what needs to be done as that support becomes available.

So the algorithm for the mozilla installer would be something like:

1) Find most current JRE on machine by looking at registery keys
2) If version is pre 1.4 copy appropriate files into "plugins" directory
3) If version is 1.4 run regxpcom on appropriate file.
4) If version is post 1.4 run well known command at well known location to
insure plugin is properly installed.

Comment 7

[Peter Lubczynski]

The problem with the copy [done by the browser] is that the JRE (1.3)
uninstaller probably won't know about these copied DLL's and therefore if used,
the JRE won't be there but the DLLs will. This may be acceptable to some
embedders (like Mozilla, maybe Netscape) but maybe not others (like AOL). That's
why there is a optional scan done with a hidden pref.

Would could be nice is if the JRE installer could be re-run without being
downloaded. Sort of like a setup-script, maybe similar to what happens when you
check "Netscape 6" in the JRE control panel. It could then enumerate through the
Windows registry keys that Gecko embedding browsers write for discovering
plugins and determine the most optimal way of installation (whether copy,
regxpcom, or something else TBD) for each browser.

Comment 8

[Steven Katz]

WRT #7

Peter, your second paragraph is almost exactly what I am proposing.  I don't
think however that the command should effect ALL gecko browsers.  I think the
scope should be limited to the gecko browser that initiated the installation
request.  In short I can envision a situation where a users might not want the
JRE installed against all possible gecko instances when they ask for it to be
installed aginst a particualr one.

In short, in the future, there should be a way for a given browser to request of
the plugin that it install itself into that browsers environment (assuming that
version of the plugin knows how to support that browser).  [If we really wanted
to we (the JRE) could keep track of all the places we have been asked to install
ourselves and when we are unistalled we could clean thoses places up]

Comment 9

[Daniel Veditz [:dveditz]]

WRT comment #7, JRE 1.3 is what it is -- if we want to make it work we have to
copy the .dll's. I'm all for Steven's proposal in comment #6 where if we can we
do the appropriate action for existing versions of JRE, moving toward the future
where the JRE exposes an API that will do the right thing even as the right
thing changes from version to version.

Comment 10

[Peter Buxton]

The following Registry keys (or the subkeys therein) all point to the Javasoft
package to which Mozilla points:

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\jarfile
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\javaw.Exe
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{8AD9C840-044E-11D1-B3E9-00805F499D93}\

Those last two, I think, are more random and harder to search for; the first two
do give the location of the java install--and some give the version number. All
you would have to do is look in: 

${absolute file name found above}\bin\NPOJI600.dll

to find the appropriate plugin for Mozilla. As it is, this bug is a real biter
if you haven't encountered it before, and may indeed be a severe discouragement
to non-techies. As it is, I found its sister bug on Linux:

ln -s /usr/local/jre1.3.1/plugin/i386/ns600/libjavaplugin_oji.so
/usr/lib/mozilla/plugins/libjavaplugin_oji.so

so had a clue to begin with. Mozilla claims the Java install was a success but
DOES NOT copy the above .dll file NOR does it tell you to do so! Again, very
harsh for non-techies.

But all's well that end's well; Java is now working as well as IE/MS Java and
Mozilla is a great browser. Thank you.

Comment 11

[Steven Katz]

I have submitted an RFE in the sun bugtrak system requesting that a scheme for
initiating the connection of the plugin to the browser from an independent agent
(i.e. the browser's install) be implemented.

See BugTraq BugID: 4633327

Comment 12

[Peter Lubczynski]

This is has been FIXED for a while. Mozilla now has a pref (on by default) to
locate and scan for the JRE in it's installation folder. This fixes the "first
install" problem, does not require users to copy DLLs, and does require to run
the JRE installer after installing the browser. The pref is version bound and
located in winpref.js.

Comment 13

[shrirang khanzode]

true, v