Closed Bug 100580 Opened 23 years ago Closed 23 years ago

Can not install Sun Java plugin

Categories

(SeaMonkey :: Installer, defect)

Product:
SeaMonkey
Component:
Installer
Platform:
x86
Windows NT
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME

People

(Reporter: xiaobin.lu, Assigned: slogan)

References

(
URL
)

Details

(Keywords: relnote, Whiteboard: [PDT] [Need ETA]) 

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)
BuildID:    2001091303

Mozilla 0.9.4 by default put two java plugins dll file into plugins directory. 
However, if I remove that two files and ask the browser to download, the 
browser will give some information like this:
Install Results
Java 2 Plug-in for Windows : Download was unsuccessful. Please try again. The 
Java Plug-in is 7.6Mb and will take you 37 minutes to fully download with a 
28.8 modem or 19 minutes with a 56K modem. Alternatively, you can download this 
plug-in directly from our FTP site at 
ftp://ftp.netscape.com/pub/netscape6/english/6.0/windows/win32/smartupdate/jre13
i.exe for Windows. Please e-mail ftp-plugins@netscape.com if you continue to 
have problems. Error encountered -- -228

Reproducible: Always
Steps to Reproduce:
1.Make sure you don't have java plugins dll in your plugins directory and go to 
java.sun.com
2.Click the "get java plugin", a dialogue box will pop up to remind you to 
download plugin
3. Finally the browser will give you some information as I mentioned above.

Actual Results:  Nothing has been done to get plugins.

Expected Results:  Java plugin should be copied to the plugins directory.

I don't think it belongs to our OJI module.
Copying the files into the Mozilla plugins folder doesn't seem to work
either ... or not reliably.

I went to http://java.sun.com (just to pick a page requiring Java). It told
me to get the plugin. So I clicked on the puzzle-piece and it went to fetch
the files from the Netscape site.

I copied the files NPJava130_01.dll, NPJava130_01a.dll, NPJava130_01b.dll,
NPJava130_01c.dll, NPOJI600.dll to the Mozilla plugins folder and restarted
Mozilla. about:plugins then gave those plugins as being present. Go to 
http://java.sun.com and it still asks me to get the plugin ...

This is Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20010913
(that's Milestone 0.9.4), running on NT4sp6a on a Compaq Armada M300 notebook.
PIII-600, 320 meg memory.

If there's any more useful detail I can provide, please ask.
Actually, that last comment was complete rubbish. I went and
double-checked, and I had in fact copied all files except
NPOJI600.dll . Shut down Mozilla, copied file into Mozilla
plugins folder, restarted Mozilla and now Java works fine.

My sincere apologies for clogging your mailboxes with an
erroneous report.
confirmed on Windows2000 machine
Download of Java takes place, but when I go to applets site, the puzzle piece 
displays again.
in Plugins directory there is only one file  npnul32.dll
Status: UNCONFIRMED → NEW
Ever confirmed: true
Grace, you do not get the -228 download error? Does the install.log say anything
useful?

flagging to the pdt, this is quite serious if it's more than an isolated case.
Keywords: nsbranch
Whiteboard: pdt
I'm using Win95a with the zipfiled download of 0.9.4 and I also encountered this
bug. I went to a Java site, clicked on the icon, downloaded it, and it still
showed the icon. npnull32.dll is the only thing in plugins. I tried installing
the plugin twice, uninstalling it after the first time. Installing manually
using David's method worked.

I'm not sure if this matters, but my setup is a bit unusual; I have Mozilla
installed on my second partion, but Netscape 4.6.2 still exists on my C: drive.
I'm mentioning this because I noticed that the Java files listed in David's
comments are in the plugins directory in the Communicator directory (except for
NPOJI600.dll)

The install.log looks normal; it shows this:

ftp://ftp.netscape.com/pub/netscape6/english/6.0/windows/win32/smartupdate/jre.xpi
 --  09/22/2001 03:53:23
-------------------------------------------------------------------------------

     Sun Java 2
     ----------

     ** initInstall() returned: 0
     ** execute() returned: 0
     [1/1]	Executing: C:\WIN95\TEMP\xpinstall.exe

     Install completed successfully
     ** performInstall() returned: 0
     Finished Installation  09/22/2001 03:53:32
Reenforcing Grace Bush's report of 2001-09-21 14:23...

I'm running Windows 2000, I clicked on the puzzle piece when it offered
to download jre 1.3 and completed the download process without any 
apparent errors.  I verify that C:\Program Files\JavaSoft\JRE\1.3.0_01
was created and appears to be complete.  I also note that
C:\Program Files\mozilla.org\Mozilla\Plugins only contains one file, npnul32.dll.

I quit mozilla and restarted (rebooted, to boot).  Re-visiting the site that
wanted the java plugin, I'm saddened to see the puzzle piece, still offering to
download the jre 1.3 plugin.

I'd be happy to repeat the process and look for any anomolies, if told where to
look.  Many thanks.
Kindly take me out at sunrise and present me to the firing squad, but for my
last wish, allow me to rescind my previous post: manually copying the jre plugin
(NPOJI600.dll) to the mozilla plugin directory and re-starting mozilla was all
that was required.  Just like it said in the release notes.  'pololgies.
Syd, Can you let us know if you (or someone on your team) can fix this and get
the reviews in the next few days?  This seems fairly serious so I'd like to get
it on the PDT radar for eMojo branch check-in consideration.
Dan, who wrote the Java installer scripts?
Keywords: nsbranch → nsbranch+
QA Contact: bugzilla → gbush
On windows it's a native executable, with a minimal .xpi wrapper to launch it
(wrapper written by rebron@netscape.com I think).

The problem appears to be that the plugins aren't being copied correctly. I
expect this result when people unzip a mozilla tarball instead of installing.
Those folks will consider it a bug of course, but no one has told Sun how to
find mozilla in that case.
For installed builds the sun installer used to look at certain registry keys to
find the build. Either we stopped registering those keys in the same way, or the
sun installer stopped looking in the right place. If we're talking about the old
1.3.01 JRE it's hard to believe the latter, but it's possible the new JRE 1.3.1
installer changed on Sun's part.

Sean would remember the registry key it's supposed to use, and the Sun guys
should confirm that. Then people having the problem should look and see if that
registry key is set in a way the Sun installer would understand. Depending on
the answers we can go from there.
The bug that contains the registry info is:  bug 77244

The new official keys are:
 1. HKEY_LOCAL_MACHINE\Software\Mozilla\Product x.y\bin\
    'bin' will contain the path to the Mozilla based browser executable:
    e.g. the Value and Value-data pair will be:
    PathToEXE="C:\Program Files\Netscape\Netscape 6\netscp6.exe"

 2. HKEY_LOCAL_MACHINE\Software\Mozilla\Product x.y\Extensions\
    'Components' will contain the path to the Mozilla Components dir:
    e.g. the Value and Value-data pair will be:
    Components="C:\Program Files\Netscape\Netscape 6\Components"

 3. HKEY_LOCAL_MACHINE\Software\Mozilla\Product x.y\Extensions\
    'Plugins' will contain the path to the Mozilla Plugins dir:
    e.g. the Value and Value-data pair will be:
    Plugins="C:\Program Files\Netscape\Netscape 6\Plugins"

The old keys are still being set, they are:
  key : HKEY_LOCAL_MACHINE\Software\Mozilla\Seamonkey\
  name: CurrentVersion

  key : HKEY_LOCAL_MACHINE\Software\Mozilla\Seamonkey\[CurrentVersion]\Main
  name: Program Folder Path

The value of Program Folder Path is the folder where mozilla.exe (or 
netscp6.exe) is located at.  From there, one can get to the Plugins sub folder.

Looks like this might be in the Sun installer = PDT-
Keywords: relnote
Whiteboard: pdt → PDT-
A little remark: you seem to consider this a new thing but AFAIR, I've never
been able to install the Java plugin on Mozilla without manually copying the
.dll file. It might be one year old or so. Or maybe the problem was there, has
been corrected and then has regressed.
Patrick: do you use the mozilla installer, or just unpack the .zip file? If you
use the .zip file then this is expected because the JRE install won't know how
to find mozilla.
At the beginning, it was with the zip file, the only one to have talkback by
then. Now, it is with the installer and I made a fresh install recently. But
indeed, in this case, the problem might not be that old.
Dan,
I can reproduce with the Installer- (just the same as noted here by others)- I
did get JRE installed but no .dll in plugins.  I copied it over per other posts
and I am working now.

I think we need to reconsider the PDT-: if the Sun installer had changed Xiaobin
likely wouldn't have written this bug. People are still redirected to
http://home.netscape.com/plugins/jvm.html which is still serving the JRE from
the 6.0 directory. Absolutely nothing has changed in that sun plugin, so it's
got to be on our end.

This raises the issue about updating that page to serve the 1.3.1 JRE that will
be certified with eMojo, which means either adding additional code to that page
to sniff browser versions, or changing npnull32.dll to redirect to a different page.
Whiteboard: PDT- → PDT
Whiteboard: PDT → [PDT] [Need ETA]
The Sun Java installer that is eventually run by following the link from the
puzzle-piece plugin DOES NOT recognize our NEW registry solution. An updated one
 from Sun may, and actually, I hope we change the link for mozilla to point to
the JRE 1.4.

One solution is in bug 78150. This does a reverse scan and tries to pick up the
Java plugin based on the registry keys it writes. In fact, one of our embedding
partners is using this to get around this problem. It's already in the builds
and can be activated by adding this pref:
pref("plugin.do_JRE_Plugin_Scan",true);

Also, please correct me if I'm wrong, but I don't think Netscape commercial
builds are effected because I think the old 1.3 JRE installer attempts to find
Netscape 6 by another, older, registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Netscape\Netscape 6\6.2 (en)\Main

Grace - on your comments about being able to reproduce this, are you using the
commercial build? Thanks.
I just reproduced with branch commercial build.
This was on NT 4 by the way.
This was on NT 4 by the way.
Well, here's what I experienced.

Windows NT 4.0 SP 5: Install new version of browser. Plugin not yet installed
anywhere on machine, click on the puzzle piece, XPI download happens, error
message displayed in a browser window at the end, native Java installer does not
launch. Bummer.

Windows ME (tm): Install new version of browser. Plugin not yet installed
anywhere on machine, click on puzzle piece, XPI download happens, native
installer runs, native installer completes, Java runs, woohoo.

Hrmmm, maybe this is something to do with NT vs 95/98/ME

Windows NT 4.0 SP 5 (different machine): Install new version of browser. Plugin
already installed, uninstall JRE, uninstall browser, reinstall browser. Click on
the puzzle piece, XPI download happens, native installer runs, native installer
complete, Java runs, woohoo.

Hrmmm, maybe not an NT vs. 98 issue.

Return to the original NT 4.0 SP 5 machine where I failed above. Uninstall
browser, reinstall browser. Reboot machine. Click on the puzzle piece, XPI
download happens, native installer runs, native installer complete, Java runs,
woohoo. Ok, so, why did it work this time?

At the same time, peterl installs a couple of times on Windows NT 2000 without
any problems.

So, I am 3 for 4, peter is 2 for 2. 

This was the 10/03/2001 Windows Commercial Branch build.

Seems like we always download the files. When I failed it was unable to launch
the native Java installer. Is there some random flako bug in the engine that
could cause us to not be able to fork and exec (Unix speak for the Windows
equivalent) the Java native installer?
Can anyone who is duplicating this repeatedly try uninstalling the browser,
rebooting the machine, re-installing, and see if it clears things up? 
Tested with Mozilla build of 2001100103, it seems works fine. The only problem 
is the installer doesn't copy the dll file into the mozilla plugins directory 
even the mozilla is installed using Mozilla installer.

I guess this is a problem in XPI installer script written for JRE installer.
Following comments are from dveditz. Could someone try these out and respond
back here with results?

I remembered a bug Teruko wrote about not being able to upgrade JRE 1.3.01 to
1.3.1, possibly on a Japanese system, I don't remember all that well. I propose
the theory that this bug ("skip JRE install if already existing") may be the
root of the problem. Test steps would be

1) install N6 w/Java, or add Java after the fact.
2) visit java.sun.com or warp/java to make sure Java works
3) install N6 into a fresh directory w/out Java
4) visit site with Java (shouldn't work)
5) click puzzle piece and install
6) visit java site to see if it works

If my theory is correct Java will *not* work in step 6 and that install of N6
won't have the java plugins. If you relaunch the first N6 you should find that
java still works.

If this is the case then it's basically from the bug Teruko described and is
really a problem that will have to be solved in the Sun native JRE installer.
There may be a way to hack the wrapping .xpi to solve this problem. But first we
have to reliably reproduce the problem, so we can have an educated guess about
how widespread the problem may be.

Xiaobin: this is a windows bug, the XPI script simply runs the Sun installer.
The only way it could be a bug in the XPI is if the sun installer didn't get run
at all -- but it does.
I don't know why this is a windows bug. Should Sun's installer find the 
mozilla's install directory from Windows registry and copy all the dll files 
into the mozilla plugins directory? 
This is a "windows bug" in that the symptoms are unique to the windows version.
The linux version of the JRE install is a pure XPI script, and that script
creates the link to the plugin. The Sun native JRE *used* to copy the plugins
(based on win registry settings), and still does copy the plugins in many cases,
but for some number of people it does not. We're still trying to figure out when
and why, but it's hard since the JRE installer on windows is a black box to us.
>> Should Sun's installer find the 
>> mozilla's install directory from Windows registry and copy all the dll files 
>> into the mozilla plugins directory? 

Yes, yes, yes!!! I think this would solve a bunch of problems and really help
our embedding partners. The native installer  (for 1.3) looks at the WRONG
registry keys. The correct way to install plugins on windows to work with all
copies of Gecko on a system is outlined in bug 77244.

Has anyone tried Syd/Dan's steps? I think step #4 is incorrect because it has
been my experience that even if I choose NOT to install Java, if it is already
installed (as proven by the previous steps), the installer finds and copies the
correct DLL's to the new installation plugins folder and Java should work out of
the box.


Peter, you're right I forgot that our windows installer attempts to find an
already-installed JRE (people complained bitterly that they had to download the
JRE every time when obviously it rarely changes). Please add step 3.5:

3.5) delete the java plugins from the newly installed plugins directory

It would be great if a future version of the JRE looked at the correct Gecko
registry keys but that's a different bug/RFE. The Mozilla/N6 install *does* set
the old keys and we're still using an old JRE which looks at those keys, and for
some large number of people it's failing to work.
You may also be missing the EVER so important step 5.5:

5.5) Once the native installer has finished, click on the puzzle piece AGAIN,
this time is SHOULD say "After installing the plugin, click here" If it does not
say that, visit about:plugins to verify it got installed anyway.

I have seen many reports of confusion at this point where one would just reload
the page or open a new browser window instead of clicking on the puzzle again or
going to about:plugins. This does not trigger the very important
navigator.plugins.refresh() which causes the newly installed plugin to be
registered.

Possibly, the page that reports a "Succesfull Install" may want to issue a
navigator.plugins.refresh(0) which reloads plugins but does not reload the page.
...actually, that comes up before the native installer is finished. :( I think
the xpi script that users are pointed to download may need to be updated to wait
for the native installer to finish before issuing a
javascript:navigator.plugins.refresh()

I'm also thinking of another solution for later on, partly using dp's plugin
caching in bug 101769, that would try to do a partial plugin scan before giving
up to show the default plugin.
Dan,

I tested this  using your steps- with modifications noted(having uninstalled both
Java and current N6 installation
steps 1,2,3,3.5,4- all worked as expected
at step 5- puzzle piece displayed but when I clicked on it, the download page
came  up but disappeared just as fast.  I tried many times but it did not allow
me to download
I went to netscape download/jvm.html and downloaded- which installed JRE 1.3.0 
(my step 1 installed JRE 1.3.1)
Step 6 - I was able to use java applets

about:plugins shows the 1.3.0 files installed at step 5

Peter: the default plugin points at a page that always downloads the 6.0 version
of the JRE. In 6.1 we added an install feature that allows install scripts to
block on a native install, but this isn't getting used here. This page needs to
sniff and download the correct install package, especially since 6.2 is shipping
with the 1.3.1 JRE.

(additionally, there's no need for the page to present two platform-specific
buttons, it could easily present a single button that does the right thing.)

Is this bug heading for WORKSFORME? No one has presented steps that reproduce
the problem.
Today I downloaded and installed a nightly (2001100803) from scratch with jre
already installed. 
And Lo and behold, this bug reared up its ugly head again.
First Moz failed to download the jre, in the second try it installed, but Moz
didnt detect the installed jre. Only copying the NPOJI600.dll to the \plugins
directory solved it.
I saw this bug months ago and thought it was since fixed, but apperently not.
The install notes with 0.9.4 say when having problems with the jre plugin to
copy the NPOJI600.dll by hand. But I think this is a major problem for a lot of
users, copying this file while installing Moz shouldnt be that hard should it?
BTW im using said nightly and windows 98. So this is not an NT problem.
Ok, so my thinking this is an argument passing thing can't be because looking at
the install.js that is bundled in the xpi file, no arguments are being passed.

Bas, can you attach the installer log file (install.log, located in the
directory you attempted to install to). If you have successfully installed JRE
after reporting the bug, then don't attach the log. But if you haven't yet, or
if you are able to reproduce this for us, then that log may provide some clues
we are looking for. Thanks.
Okay, I think I know what people are talking about in this bug.  Here are the 
problems I see being talked about in this bug regarding 
ftp://ftp.netscape.com/pub/netscape6/english/6.0/windows/win32/smartupdate/jre.x
pi :

 1) Attempting to download and install JRE gives: Error encountered -- -228  
(DOWNLOAD_ERROR).
    This means that JRE was not successfully downloaded, so there's *no way* 
that its plugins could have been installed.

 2) JRE downloaded fine and its installer ran fine, but jre plugins have not 
been installed properly.

 3) This one has probably not been encountered here, but is related to this 
problem: JRE has downloaded, but its installer never runs.
    This is probably bug 100183

Most people commenting on this bug have been complaining about 2), not 1).  1) 
seems quite unreproduceable.  My take on it is that it could have been ISP 
problems, server end problems, or even just a bad internet day.  Xiaobin, are 
you still running into error -288?

As for 2), it's not a problem with the mozilla browser or jre.xpi file.  The JRE 
installer (which jre.xpi simply runs after download is complete), at one point, 
copied ...\bin\np*.dll to ...\mozilla\plugins folder.  It does not look like it 
is still doing that.  The windows registry keys that the mozilla installer 
registers for this copy to succeed is still being set.  See my earlier comment 
in this bug from 2001-09-26 01:00

Basically, there are two situations that the JRE plugins need to end up in 
...\mozilla\plugins:
 1.1) When user installs JRE *after* Mozilla has been installed.
 1.2) When user already has JRE, then installs Mozilla.

In scenario 1.1), the JRE installer need to perform the actual copy of its 
plugins into ...\mozilla\plugins folder.  Mozilla is not going to know anything 
about it.

In scenario 1.2), the current Mozilla installer *does not* copy the JRE plugins 
into its ...\mozilla\plugins folder.  This was done at one point, but was 
requested to be stopped.  The reason was that at that time, Mozilla was very 
picky as to which version of JRE it worked with, so to minimize erroneous bug 
reports, it was stopped.  There currently is not a bug filed against this 
scenario.

As to fixing scenario 1.1), the real fix needs to be applied to JRE's installer.  
A "workaround" can be done in jre.xpi because of a new feature that offers the 
ability to wait for JRE's installer to finish before continuing.  This means 
that jre.xpi can attempt to locate where it's plugins are and copy them to 
...\mozilla\plugins.

However, if someone downloads the JRE's installer itself (jre13i.exe not 
jre.xpi), then this "workaround" is useless.

And finally, 3).  If you run into that situation, please go update bug 100183.

The problem I have seen seems gone.
Closing this bug as worksforme, per Xiaobin's comment on the original problem 
in this bug.

If people want 2) (from my previous comment) addressed, please file a new bug.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
original problem worksforme
logged bug 104387 for problem2 as detailed by ssu
Status: RESOLVED → VERIFIED
Comment-  just loaded Mozilla 0.9.9 on my Win2k machine, complete install.  Went
to a site that uses java, told me I needed the plugin still.  Installed it,
restarted Mozilla, same result, I still need the plugin.  Found this bug, copied
NPOJI600.dll into the plugin directory which was still not there, whereas the
other 4 files mentioned HAD been copied there by the install.  (Whether by 0.9.9
or the java install, not sure...)  

Regardless, I am writing this comment with the main concern that this be
addressed before release 1.0, because users will be immediately unhappy if Java
does not work easily.  If anyone knows and can point me to the appropriate bug
that is fixing this or if it is being fixed in the java installer, please direct
me to the appropriate bug...  I am sincerely hoping that the PC community starts
using Mozilla as well.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.