Description of Problem: Mozilla downloads the wrong JRE
when it encounters a web page that needs a version 1.3.1
Java 2 plug-in.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Invoke mozilla
2. Go to page that requires a JRE 1.3.1 Java2 plug-in.
3. Make and check a hard link (cd /tmp; ln jre131i.xpi something;
sleep 3600; unzip -t something)
Mozilla downloaded an i386 JRE, which is not correct for an Alpha
machine. (X86 may be the worst surviving instruction set architecture
on this planet, but it's certainly not the only one.) Then, mozilla
pops up a window instructing the user to downloads a Losedows version
of the plug-in:
Mozilla should download a JRE appropriate for the architecture on
which it is actually running. Or, better yet, if possible, it should
use the existing JDK already installed on the machine.
I apologize for not being able to provide an URL that shows the
problem. One case I saw was money.net's free 14-day trial for their
streaming real-time stock quote service. Another is the charts page
on my stock broker's web site, and an account with the broker is
required to get to that area. (It appears a fairly reliable predictor
of a page that will show this problem for Mozilla is a page that will
cause Netscape 4.77 to throw a segment fault.)
So what would be the right behaviour here? I don't think that we have a working
JVM for mozilla for the alpha, right? Should I just disable the dialog?
That would be better than the present behavior. If Mozilla requires a whole
separate from a JDK the user might have already have on the machine, and if
there is no
downloadable JVM for the architecture in question, then it would be better to
user that no JVM exists for that machine.
JVM exists for Alpha, the problem is with the plug-in.
So, it would be better to inform the user that no plug-in exists for that machine.
Where is the JVM?
I fixed this in the 0.9.9 build by not allowing the plugin downloader to go to
the downloader site. Downloading and installing a .xpi as a user doesn't work
correctly in any case.
Anyway, fixed in the last 7.2 errata.