Closed Bug 84463 Opened 23 years ago Closed 23 years ago

Despite installing Java through Mozilla, no Java works

Categories

(Core Graveyard :: Java: OJI, defect, P3)

x86
Windows 98

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 100393
mozilla1.1alpha

People

(Reporter: silvertree, Assigned: leaf)

References

()

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.1+) Gecko/20010606
BuildID:    2001060620

This has occured to me with every build of Mozilla I've ever used on this
machine.  Going to any website that has Java content (java.sun.com is a good one
to use; there's a java applet bit in the bottom right corner of the sidebar)
comes up with the 'Click here to install the plugin' box.  Java is installed on
the machine; I've reinstalled it by clicking on that plugin box, downloading the
executable from Netscape, and running the installer.  [Multiple times.]  Every
time, Mozilla says that the installation was successful; going back to the
website and clicking where it says 'After the plugin is installed, click here'
returns it to 'Click here to install'; restarting Mozilla doesn't fix this.  I
don't remember the first build I saw this on--M13, perhaps?--but it's never
worked for me.  I can go to the control panel and see that Java is properly
installed; clicking on the config tool I note that 'Enable plugin' is checked.

Reproducible: Always
Steps to Reproduce:
1. Go to http://java.sun.com
2. Install JRE 
3. Restart Mozilla if you like
4. Go back to http://java.sun.com

Actual Results:  Java doesn't run on any page.

Expected Results:  Java should work.

The machine is a 1.1GHz Athlon running Win98SE with 512MB RAM.  I had the same
problem on my last machine--a K6-3 450 with 64MB RAM running the same OS.
Just to test, I went to Sun's website and downloaded the 1.3.1 version of the
JRE and installed it instead (http://java.sun.com/j2se/1.3/jre/).  Still didn't
work.
Silly question perhaps, but have you enabled Java for web pages? I believe it is
disabled by default. Look under:
Edit/preferences/Advanced - checkbox "Enable Java" under "Features that help
interpret web pages"
If you install Sun's JRE by yourself, don't forget to copy some dll to Mozilla's
plugin directory :
NPJava*.dll and NPOJI600.dll
If you have netscape 6 installed the plugin download will dump the dlls in the
netscape plugin directory
R.K.Aa: No, that was enabled.

It seems, however, that copying the .DLL files from the JavaSoft/bin directory
fixed the problem--Java works fine now.

I'll switch this one to FIXED, but I must ask: is this documented anywhere?  I
never found that as the answer to the problem, although it /does/ make sense
from a techie standpoint.  [Yeah, non-techies shouldn't be using non-milestone
releases, but this didn't work when I downloaded Moz0.9 either.]
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
the mozilla-win32-installer.exe automaticlly copies all the needed files for 
java to work.
So just use:
http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32-installer.exe
and you're home free....
Ah.  I always use the packages (mozilla-win32-talkback) instead of the
installer; that explains the problem.  Thanks; appreciated.  I /do/ believe that
this should be documented somewhere, though.
"the mozilla-win32-installer.exe automaticlly copies all the needed files for
java to work."

IOW, you need to have the latest java VM intalled when you install Mozilla.
Oh, ok, that explains why I havn't been able to get java working in 0.9 since my
last Format c:.
Also, it means that downloading an upgraded java VM won't benefit your current
Mozilla version unless you fix it manually (?).

I'm sorry, but as I've read 0.9.1 is to become the next NS6 release this is
going to generate a LOT of problems for all the ordianry users out there.

Thus strongly suggest opening this bug up again so NS people notice it and
include a proper (automatic) solution for the NS6 release.
Makes sense to me--it definitely is an issue.  I'll reopen the bug, in the hopes
that someone notices it and figures out a way to add the ability to 'detect' a
previous Java installation in Mozilla.  It's definitely a bug that installing
through the web doesn't actually add it to Mozilla.
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
Xiaobin owns auto-install issues.  Over to him.
Assignee: edburns → xiaobin.lu
Reporter:
    Please notice that currently the only way to make all these thing work is 
installing mozilla using installer, not unzip zip file, not debug build etc. 
Because when you install mozilla using mozilla installer, after finishing 
installation, it will update the registry and when you download JPI, it will 
look up the registry to find out the mozilla install directory so that it can 
copy all the plugin DLL files into plugins folder. Otherwise it won't work. For 
other installation ways, the only way to get out of this problem is to manually 
copy all the NP*.dll ( especially NPOJI600.dll file) from ${JavaHome}/JRE/bin to 
the plugins folder of mozilla, where ${JavaHome} is where your JPI is.
I understand that.  I just don't think that it's an adequate answer for down 
the line.  People expect to be able to 'install' Mozilla (even if that's just 
unpacking) and Java work, if they have it installed.  And if /not/, then 
they /definitely/ expect that, if you download Java through the 'click here to 
download' scheme when you see a Java applet, it will work post-install.  Right 
now, however, that is not the case--you /still/ have to copy the plugin files 
over after you install through Mozilla.  This is Not A Good Thing.  I can 
understand having to copy the files over if you do a nightly build, but Sun's 
installer should perhaps detect Mozilla on the machine and throw the plugins in 
the proper directory.  I'm not sure as to the best solution to this--all I know 
is that the current situation is inadequate.
As I know, currently there is some open bugs which hinders the xpinstaller 
from detecting where Mozilla is being installed when no registry key was found 
for mozilla. However this is another issue which XPInstall group will solve. I 
would like to close this bug if there is a way to make java plugin to work.
Fair enough.  As long as someone has knowledge that this is an issue and is 
working on it, closing this one is fine.
"I would like to close this bug if there is a way to make java plugin to work."

Well yes, this is just a minor nuance in Mozilla (though it would need better
documentation in the releasenotes) so in that (very narrow) aspect it can be
closed (after updating the rel notes...).

However if we take a few steps back and look at it with a broader view,
including NS6 and the general public, I would call this a Severity BLOCKER bug. 
This is a really really really bad bug that under no circumstance may be allowed
to reach the everyday user (it's right up there with the "can't install"
problems of the previous NS6 release, real major goofup).

Whatever you decide to do with this bug is fine, as long as you make shure that
it is fixed before NS6 hits the streets.
I just suggested keeping it open so that people "in the loop" don't lose focus
on it. If there is a better way to do it, please use that instead.

But if this one "slips though the net" I'll... I'll... I'll stop posting bugs
here ,-).
*** Bug 85593 has been marked as a duplicate of this bug. ***
Reporter:
    I don't think there will be problem for Netscape 6 because anyway people use 
xpinstall method to install Mozilla and that way, after the user finishes 
installing Netscape, there is  a registry key put to the windows registry 
system. So the next time when user installing Java plugin, the jre installer 
will find that registry key so that it will know where to put the plugin dll 
files to. 
   The only problem I can see is for those people downloading mozilla zip files. 
because at that time no registry key will be put into the registry key system 
and jre installer has no way to know where to put the dll files. 
  I will put these installer issue for linux and windows platform in 
www.mozilla.org/oji. Let me know if I can close the bug.
This bug can be closed--as long as someone's working on getting this working,
/even for the zipped versions of Mozilla/.  Doing something as simple as adding
instructions to the documentation that comes with Moz, or fixing the Java
installer to detect the 'merely unzipped' version, is fine--as it is, though,
the fact that you can install it from the browser and yet it doesn't detect
Mozilla (regardless of the fact that I didn't use the Installer) is not good.  A
disclaimer on the milestone pages and the build pages saying that Java won't
work if you don't use the installer would be fine.
ssu:
   Please comment here about the last comment. Thanks in advance!
Here are the problems I'm seeing:
1) There's a mozilla .zip file on mozilla.org for people to download.  There 
doesn't seem to be any information on it regarding issues with JRE, like 
copying np*.dll from the Java's plugin folder to the mozilla's plugin folder, or 
using the .exe instead of the .zip file.
2) Sun's JRE installer is not detecting this particular installation type and 
therefore not installing its plugins appropriately.

We can do something about 1) from mozilla.org, but won't be able to do anything 
about 2) (it's not our installer).

Dawn, is it possible to not offer the .zip file to the users anymore?  Isn't the 
installer sufficient?  This would also solve other problems inherent to not 
running the .exe installer.  If not, can we put info regarding JRE problems when 
using the .zip file?
ssu:
   Thanks for your comment!
*** Bug 85013 has been marked as a duplicate of this bug. ***
we could probably slap a readme into the .zip files, or write a page with .zip 
package issues to link from the download page.
Leaf:
   I think it is good idea to do it. Can you do it?
Leaf, what was the ogirinal purpose to offering the .zip file?  Has that purpose 
been fulfilled now?  I rather not deliver the .zip file if at all possible.  The 
installer is starting do more things during installation which might be required 
by 3rd party apps.
Just for the record...

Java_isn't_working_automatically_even_with_the_.exe download !


IOW, the below doesn't work (in Moz 0.9.1 win98se)
--
after the user finishes 
installing Netscape, there is  a registry key put to the windows registry 
system. So the next time when user installing Java plugin, the jre installer 
will find that registry key so that it will know where to put the plugin dll 
files to.
--

I'm still not getting functional Java using the Moz install.exe while already
having JavaVM on my system OR clicking a "get this plugin" (even though it seems
to install correctly).

In short, this is still severly broken.


A small related note, why on earth is the NS download still JavaVM 1.3.0_01 ??

There has been both
1.3.0_02
1.3.1 (current latest)
Any NS people reading this, fix that =)
*** Bug 84590 has been marked as a duplicate of this bug. ***
Shrir:
   Would you please confirm sauron's comment on Win98? Thanks in advance!
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 86388 has been marked as a duplicate of this bug. ***
Leaf:
   Would you please comment on ssu's last comment? Thanks!
Originally, we didn't have installers, so that's where the .zip file came from.
The .zip file is provided now to test the functionality of the stuff in dist/bin 
as opposed to things that are put into the installer through the installer 
manifests, which are *frequently* not updated by people that add files to, or 
modify files in, dist.

This helps us differentiate problems that are caused by bad code and bad 
manifest files. Perhaps just labeling the .zip files as "for smoketest purposes 
only"; there's no executable anyone can run to make .zip files work?
leaf, that sounds great to me.  The mozilla download page already looks better 
than before, but I like your suggestion even better.
Leaf:
   Can I assign this bug to you to mark the zip file as "smoketest purpose 
only"?
   Thanks!
*** Bug 86882 has been marked as a duplicate of this bug. ***
*** Bug 86893 has been marked as a duplicate of this bug. ***
Reassign to leaf@mozilla to update the documentation.
Assignee: xiaobin.lu → leaf
Priority: -- → P3
Target Milestone: --- → mozilla1.1
This bug is broader than reported above, and in recent discussion.

- I experience the same behaviour under Linux (so it's not just Win32)
- I *have* used the installer build, not the .tar.gz
- I have checked to make sure that the installer did an 'ln -s
plugins/java2/plugin/i386/ns600/libjavaplugin_oji.so plugins/' (it did!)
- I've had this problem with both 0.9.1 and 0.9.2, but I was able to get Java
working under 0.9 (and I don't think I had any trouble like this)

I do notice, however, that after doing a java install, if I try to run mozilla
again that I get a dialog telling me to wait for a previous installation to
complete.  Sometimes xpicleanup is still running in the background, somtimes
not, but in general manually running xpicleanup solves the can't-start-mozilla
problem, but somehow induces the can't-start-java problem...  :-(

(Perhaps someone can explain xpicleanup to me, so I can provide a more useful
explanation of whatever's happening.)
I installed build 2001081208 this morning (which has other issues) and noted
that it did /not/ pull my Java plugin from the JRE 1.3.1 installation.  This was
a proper 'installation', using the magic Installer program for nightly builds
with the automagic download and so on.  This is definitely problematic.
SPAM: reassigning all OJI bugs to new OJI QA, pmac ( 227 bugs)
QA Contact: shrir → pmac
*** Bug 101909 has been marked as a duplicate of this bug. ***
As of 0.9.6, I was able to successfully install Java in the usual way, and it
worked!

I tried this under linux.  It still works in 0.9.7.  Yay, Java!

Can other people with recalcitrant Java installation problems check to see if it
works for them too?  Perhaps it's time to close this bug, finally.  (Until the
next time Java installation gets broken, anyway.)
Please look at http://gemal.dk/mozilla/java.html and see if that doesn't help you.
If it does please close this bug...
The installer isn't putting the DLLs in the right loction. See the release notes
or bug 100393.

*** This bug has been marked as a duplicate of 100393 ***
Status: NEW → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → DUPLICATE
peter beat me to this bug..verif dup
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.