Closed Bug 66840 Opened 24 years ago Closed 23 years ago

Mozilla fails to detect installation of JRE plugin

Categories

(Core Graveyard :: Java: OJI, defect)

Product:
Core Graveyard
Component:
Java: OJI
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: nrussell, Assigned: xiaobin.lu)

References

(
URL
)

Details

Attachments

(2 files)

The relevant portions of install.log for the failed install of the java plugin
9.32 KB, text/plain
Details
Output of hang when mozilla tries to start with Java2.
4.24 KB, text/plain
Details 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20010127
BuildID:    2001012708

Using the latest nightly (installed from the installer program only minutes
earlier), I went to the above URL and clicked on a game room.  Mozilla popped up
a window about needing the JRE 1.3, which I downloaded from Netscape's FTP
server as instructed.

After downloading and installing the JRE, I clicked in the game window, but was
told that I still needed the JRE.  I then closed all Mozilla windows and opened
a new one.  

Upon returning to the game, I still was unable to get Mozilla to recognize the
presence of the JRE.  I have not tried rebooting Win98, since neither Mozilla
nor the installer stated that such action was necessary.  

I lack access to platforms other than Win98 SE.

Reproducible: Didn't try
Steps to Reproduce:
1. Download and install newest nightly to a new directory (I did from installer
program, and am not sure if this is necessary)
2. Go to the above URL, logging in to Yahoo if necessary	
3. Click on one of the 'global game rooms', which pops up a new applet window
under all browsers.
4. When presented with the 'plugin needed' panel in the new window, click on it
and install the JRE.  
5. Attempt to click on the 'click here when install finished' panel.

Actual Results:  Mozilla still stated that plugin was not present.  

Expected Results:  Used plugin to display game.

I should note again that I did not attempt to reboot Win98, but that the JRE
installer did not prompt me to do so, which many Windows installers do even when
a reboot is not actually needed for proper functioning.  

I am leaving this at 'normal' severity, since plugins are not a critical feature
of the browser's usability, but I somewhat suspect it should be at least a notch
higher.  Please comment on this - I have only used Bugzilla for 2 days and this
is my first attempt at using a nightly.
This happens for me, Linux 2.4.0-test12 i686
build 2001012721
Where "happens" means "I also see the same problem"
/tmp/mozilla/plugins % ln -s java2/plugin/i386/ns600/libjavaplugin_oji.so .

appears to fix the problem.  Tested against:

http://javasoft.com/
Summary: Mozilla fails to detect installation of plugin → Mozilla fails to detect installation of JRE plugin
Changed to OJI. Marking NEW as per comments.
Status: UNCONFIRMED → NEW
Component: Plug-ins → OJI
Ever confirmed: true
OS: Windows 98 → All
Hardware: PC → All
this is a duplicate... Installing on top of existing build again and again shows 
this. However this works on a fresh install ( java plugin complately removed).
Assignee: av → edburns
I'm pretty sure my install was fresh -- I got caught unawares by the top-level
binary package directory name switch from "package" to "mozilla," and so I had
downloaded the binary package from scratch before trying this.

I did not, however, remove my ~/.mozilla directory before testing.

 
Xiaobin, can you please look at this one?
Assignee: edburns → xiaobin.lu
  The important step after installing java plugin is you need to copy all the 
NP*.dll(espaecially NPOJI600.dll) file to your SeaMonkey/plugins directory. To 
make sure you have java installed in your system, type about:plugins and you 
should see a list of plugin your system supports especially java plugin.
   Try it out and let me know if you still got problem.
Rebooting Win98 made moz recognize the plugin.  
*** Bug 67086 has been marked as a duplicate of this bug. ***
Hi Xiaobin,

Please accept this bug.

Ed
Status: NEW → ASSIGNED
I see this on linux definitely...
Severity: normal → major
  Also can be reproduced in Window2000.
*** Bug 56660 has been marked as a duplicate of this bug. ***
FWIW, I still this problem with 2001020109 on Linux. I got the gcc295 build if
that changes anything. Typing "about:plugins" shows only the default plugin as
being registered. I tried the "ln -s" as mentioned by wtanaka@yahoo.com but it
has no effect.
*** Bug 67336 has been marked as a duplicate of this bug. ***
*** Bug 67671 has been marked as a duplicate of this bug. ***
More info: I've noticed that ever since this problem showed up, I've had trouble
installing the plugin. It goes like this:

- GO to a site that requires Java
- Click OK on the dialog that asks if you want to install Java plugin
- In new window, click on "Java 2 plugin for linux" button. Let's call this
window the Java Window (JW).
- Select the entry in the ensuing dialog then click OK.
- After a while, a new Mozilla window pops up, showing the home page (I'm
guessing it's the home page because it comes up with mozilla.org which is my
home page). Let's call this window the result window (RW).
- Check in $INSTALL_DIR/mozilla/plugins. No java stuff in there.
- Go back to the JW and click the install button again; repeat the normal
install procedure.
- After a  while, the content of the RW changes to an error message. THe last
part of the message in that window says "Error 207".
- Repeat the install procedure from the JW.
- This time, the RW says that the plugin was installed. And if you look in
$INSTALL_DIR/mozilla/plugins the Java plugin has been installed.

It happens every time I install. I'm using the tar file which has the PSM stuff
in it.
Everytime I got a nightly build since November, Mozilla never registered
the java plugin (downloaded by browser or getting jre1.3_01 from sun).
Funny thing is, if you get the unsupported RPM of Mozilla 0.7 from Mandrake
this Version recognizes the jre plugin. I dont't know what they did,
but their Version works.
(Using Mandrake 7.2, kernel 2.2.17)
 Yes, I think mozilla now treats Java plugin as other kinds of plugin like 
adobe and flash media, you need to manually put java plugin files into your own 
plugins directory.I will investigate this soon.
*** Bug 68801 has been marked as a duplicate of this bug. ***
This is still valid in mozilla 0.8 and RedHat 7.1Beta (Fisher)
These are the last lines during the first startup. I directly try to install
jre.xpi.
***************************************
RegSelf Unicode to IBM862 converter complete
RegSelf Unicode to IBM864 converter complete
*** QfaServices is being registered
 I am inside the initialize
 Hey : You are in QFA Startup
(QFA)Talkback loaded Ok.
Registering plugin 0 for: "*","All types",".*"
Registering plugin 0 for: "*","All types",".*"
*** PRE date = 776
*** POST date = 792
Document http://www.mozilla.org/ loaded successfully
*** PRE date = 525
*** POST date = 532
Document http://www.mozilla.org/releases/ loaded successfully
Adding element 0 : _blank
2
Adding Progress element 0 : _blank/tmp/xpinstall.sh: /tmp/xpinstall.sh: No such
file or directory
*** Here I press the STOP button !! ***
*** Since the jre.xpi has installed itself AFAIKT ***
Error loading URL
ftp://ftp.netscape.com/pub/netscape6/english/6.0/unix/linux22/xpi/jre.xpi: 804b0002
Hey : You are in QFA Shutdown
****************************************

Now, if I look into mozilla/plugins all I can find is this:
java2/
libnullplugin

If I then do a:
ln -s ../plugins/java2/plugin/i386/ns600/libjavaplugin_oji.so plugins
And restart mozilla it hangs... 

Attached is the output of the hang. Worth noticing is that java is getting
registered now BUT twice...


/Richard
I think all plugins on Linux get registered twice.

Bug 67933 is filed for this issue with the Default Plugin (null plugin).
*** Bug 69103 has been marked as a duplicate of this bug. ***
(Windows 2K)
Is there a way to d/l just NPOJI600.dll from some ftp site?  all the other 
files (NPJava*) came down ok.
Just copied NPOJI600.DLL from another machine... worked like a charm...
is this file just missing from the .xpi?? 
Yesterday I did a fresh install of mozilla 0.8 on Redhat Linux 6.1.  I tried 
downloading the java plugin when I was prompted by mozilla by following all the 
dialogs and pages.  The download dialog indicated that the download and install 
was successful, so I restarted mozilla and returned to the original page with 
the applet.  Instead of loading, mozilla asked me to download the java plugin 
again, not recognizing the download at all.  Following the advice from this bug 
report, I looked in the plugins directory, and sure enough there was no link to 
libjavaplugin_oji.so, so I manually created the link and restarted.  Still no 
luck.  Below are the relavent lines of debugging output during startup:

********** Got plugins path: /ddrive/install/mozilla/dist/bin/plugins
IsPluginFile(/ddrive/install/mozilla/modules/plugin/default/unix/libnullplugin.s
o)
LoadPlugin() 
/ddrive/install/mozilla/modules/plugin/default/unix/libnullplugin.so returned 
81c7c90
GetMIMEDescription() returned "*:.*:All types"
Registering plugin 0 for: "*","All types",".*"
IsPluginFile(/ddrive/programs/lib/libflash.so)
LoadPlugin() /ddrive/programs/lib/libflash.so returned 81c7ca8
GetMIMEDescription() returned "application/x-shockwave-flash:swf:Shockwave 
Flash;application/futuresplash:spl:FutureSplash Player"
Registering plugin 0 for: "application/x-shockwave-flash","Shockwave 
Flash","swf"
Registering plugin 1 for: "application/futuresplash","FutureSplash Player","spl"
IsPluginFile(/ddrive/install/mozilla/dist/bin/plugins/java2/plugin/i386/ns600/li
bjavaplugin_oji.so)
LoadPlugin() 
/ddrive/install/mozilla/dist/bin/plugins/java2/plugin/i386/ns600/libjavaplugin_o
ji.so returned 0
IsPluginFile(/ddrive/install/mozilla/dist/bin/plugins/java2)
LoadPlugin() /ddrive/install/mozilla/dist/bin/plugins/java2 returned 0

So LoadPlugin() sees the libjavaplugin_oji.so file in the right directory but 
returns 0 and skips on to the next file.  Oddly it also seems to treat the java2 
directory (which is where mozilla installed the j2re files) as a plugin file, 
but LoadPlugin() ignores it too.  Incidentally, I downloaded the j2re from Sun's 
web site to a different directory and tried that too, but I encountered the same 
problem so I removed it.  I snooped around and couldn't find any other important 
java files in the mozilla dir.  Is this the same behavior everyone else is 
experiencing, or is it perhaps isolated to Linux?  Do the files from the java2 
directory need to be moved/linked elsewhere in mozilla?  Does the path need to 
be changed at all?  It seems like this was important in previous versions of 
Netscape, but I didn't read anywhere that it needed to be updated.
  I think it is the problem of the installation package. Because I checked out 
the code from NETSCAPE_0922_BRANCH, previously it automatically put all the dll 
file (.so file) in the mozilla plugins directory, right now it does not work. 
So, I suspect that Netscape ftp site removed something from the installation 
package. Shrir, can you confirm this with guyd who responsible to do this 
package?
cc:rebron, ssu
okay, the original bug references Win98 as the problematic platform.  However,
people have now also added comments regarding problems under Linux.

Win9x: There was a bug that indicated the Windows native installer copied all
the approprieate npjava*.dll files, with the exception of NPOJI600.dll.  This
would happen in the instance where the user *already* has Java installed on the
system, *and* chooses not to install it again via the Netscape installer (or
just installs the mozilla product which does not offer Java at all).  That has
been fixed.  See bug 58267.  If the problem is back, please reopen that bug.

Linux:  The linux native installer has no code to do the same thing as the
Windows native installer does.  Therefore it is still a problem under that
platform.  But from reading all the linux comments, it looks like there might be
more than a simple sym link missing, but I'm not sure.  I'll let Samir comment
on the linux platform.

The linux problem is due to bug 68356.  Mozilla users who install a recent build
and then use XPInstall to install the JRE from the Netscape site will experience
this problem on linux.  Essentially, the jre.xpi fails to create the symlink.

Since the original bug was Win98 and that appears resolved we can close this one
out.  Bug 68356 will cover the linux problem.  Go lobby in that bug if you want
it fixed.  
Before this bug gets closed I'd like to add that I finally got the java plugin 
running on mozilla 0.8 for Linux by recompiling with the following 'configure' 
options: --disable-debug, --disable-dtd-debug, --disable-mailnews, --enable-
optimize, and --enable-strip-libs (before I was using no options with 
configure).  I am fairly certain that the --disable-debug was the important 
one, something to do with a missing destructor for nsCOMPtr_base in 
xpcom/base/nsCOMPtr.cpp.  I think this problem (at least on Linux) can be 
ignored since it only affects debugging builds.  The symlink for the plugin 
still has to be created manually, but there are other bugs covering that issue 
right now.
*** Bug 69868 has been marked as a duplicate of this bug. ***
*** Bug 70136 has been marked as a duplicate of this bug. ***
*** Bug 70607 has been marked as a duplicate of this bug. ***
I just copied the "NPOJI600.dll
C:\Programme\JavaSoft\JRE\1.3.0_01\bin
to
C:\Programme\Mozilla.org\Mozilla\Plugins
restarted Mozilla and already the Java-Console becomes started. So...that´s the
problem! I guess...The Java-PlugIn is tried to be installed to (in my case) 
C:\Programme\Mozilla\Mozilla\Plugins

try to check this...I´m not able to look this up.

greetz
Rodger
People are still seeing this one windows in recent builds...
*** Bug 70719 has been marked as a duplicate of this bug. ***
OS: windows.
OS: All → Windows NT
I noticed this on my W2K machine a few days ago when I was setting up my 
development environment. I think it's a simple fix, NPOJI600.dll is just not 
being copied to the plugins folder. Doesn't the installer just need a small 
modification?
If the fix is simply the copying of NPOJI600.dll, then the Windows mozilla 
installer build should already be doing that.  This fix was checked in a few 
weeks ago.

Can someone verify this under Windows (not linux) with any recent build?
I think, the bug needs to be extended to Linux once again. With current CVS I
cannot get JRE to be recognized. I load a page with an applet, get the download
page and let the download happen (takes several hours for me). After restarting
and revisiting the page with the applet, mozilla prompts me again for
downloading Java. So the fact that bug 68356 got fixed didn't improve my
situation. I still can't get Java to work. I'm trying now with the
--disable-debug option in ~/.mozconfig. Other suggestions welcome.
Success: after recompilation with this one line added to ~/.mozconfig:
    ac_add_options --disable-debug
Mozilla recognized that JRE was installed. I did not have to download
Java again, nor did I have to create a symlink, it just worked. Thanks
to mlr3 for the hint.

I disagree with mlr3 that this is a bug that can be ignored. There are
people who want a debugging build with Java support.

In case it isn't clear from the context: I'm talking about a linux
build here. Please set OS to All again (I do not have privileges to do
so.)

Andreas,
Please file a separate bug for the linux problem since this bug was originally
intended to track an issue reported on windows.
As you requested, I filed separate bug for Linux. Bug-ID is 70856
Xiaobin, any status on this?
  I will confirm this bug in daily build in windows. I will update the status as
soon as possible.
This bug still happen in the current windows mozilla trunk build. The browser 
crash when trying to download the java plugin.
Assignee: xiaobin.lu → girish.manwani
Status: ASSIGNED → NEW
Is the NPOJI600.dll file in the mozilla/plugins folder after the installation is 
done?

The steps to check for this are:
1) on a windows system, make sure JRE is installed.
2) make sure Mozilla is not installed yet.
3) install mozilla
4) verify that NPOJI600.dll is in mozilla/plugins folder after installation is 
complete.

I had the same behaviour using 0.8 and NT4; there were no files copied to
/PLUGINS by the JRE installer.  So I copied NP*.DLL from the JRE binary
directory, and it works beautifully.  I think this is strictly an installer
problem on Javasoft's part.
   I tried the tip of the trunk this morning. The bug still happens in my win2k 
build. The file such as NPOJI600.dll is still missing in the plugins folder.

ssu:
   Could you check the window java plugin installer to see if something is 
missing? 
I will double check the windows installer code and see what's going on.  Stay 
tuned.
Xiaobin, I misread your request.  I thought you were asking about the mozilla's 
native windows installer.  What you're asking about is the jre.xpi for the 
windows platform.

I wrote the .xpi installer for jre13i.exe as a wrapper.  Meaning that the .xpi 
installer will simply launch jre13i.exe.  This means that the jre13i.exe is 
having problems locating mozilla's plugins folder.

This is probably because the place it used to look at has been changed:
  old:
      key:  HKEY_LOCAL_MACHINE\Software\mozilla\seamonkey
      name: CurrentVersion

      key:  HKEY_LOCAL_MACHINE\Software\mozilla\seamonkey\[CurrentVersion]\Main
      name: Install Directory

  new:
      key:  HKEY_LOCAL_MACHINE\Software\mozilla.org\mozilla
      name: CurrentVersion

      key:  
HKEY_LOCAL_MACHINE\Software\mozilla.org\mozilla\[CurrentVersion]\Main
      name: Install Directory

Hi, ssu:
    Does that mean I need to go to HKEY_LOCAL_MACHINE\Software\mozilla to 
manually change it to HKEY_LOCAL_MACHINE\Software\mozilla.org\mozilla? Or you 
should provide such option in the jre.xpi?
    I tried the trunk build today and it still does not work. Please fix it as 
soon as possible. Thank you for your work!!


The fix is not with the mozilla builds.  The fix jre13i.exe to locate where 
Mozilla was installed to.  Jre13i.exe is a native windows installer .exe file 
that Sun provided to Netscape.

Once jre13i.exe has been updated to know how to locate Mozilla.exe (see my 
previous comment on how to do that), here's how to test it:

1) Install latest Mozilla build
2) run new jre13i.exe

NPOJI600.dll should now be in the Mozilla/Plugins folder.
If you want this new jre13i.exe to be available via the netscape servers 
(meaning replace the current jre.xpi), please contact Rafael Ebron 
(rebron@netscape.com).
Is this getting close to 'most frequent' status?  (just curious - I don't know 
much)
Xiaobin, can you PLEASE convey to Stanley the information form ssu's post to 
this bug:

Additional Comments From ssu@netscape.com 2001-03-13 14:13 -------

Please find out from Stanley if he can update the installer to heed ssu's 
comments.  I'd like you to *own* the installation issues, which means making 
sure all the players are on the same page.

ALso, please accept this bug.
 Reassign to myself!
Assignee: girish.manwani → xiaobin.lu
Status: NEW → ASSIGNED
Hi,ssu:
    I passed what you told me to Stanley. Basically we don't want to change the 
installer which has been already shipped out. We want to know why you changed 
the registry key. If there is a big reason to do this change, I will ask our 
plugin team to do the change if they want. If there is no strong reason to do 
the change, please change them back. 
    Thanks!
The reason for changing this is because the product name isn't "Seamonkey".  
It's "Mozilla", thus:
  HKEY_LOCAL_MACHINE\Software\Mozilla.org\Mozilla

The company name is also not just "Mozilla", it is "Mozilla.org".  I had 
mentioned earlier that this was going to change in the future.  It was only 
meant as a place holder until the appropriate names could be ironed out.

My apologies for not having communicated this when the change went into effect.  
I can say that this won't be changing anytime in the near future (there aren't 
any plans to change this at all, unless we change the company name and/or 
product name).

I rather not use the old names for fear that developers will think it's the 
correct reg path.  I suppose I can put the old seamonkey keys in addition to the 
new ones until jre has been updated.  Then remove it when jre is updated.

Does anyone object (dan?) if I put the old names back for now and remove then 
when jre is updated?
ssu:
   Please do it! Thanks in advance!


      Because of the frequent changes of the Mozilla key as well as JRE key, I 
don't think we will be able to keep the JRE installer always up-to-dated with 
the Mozilla keys. Thus, here is what I suggest:

      Instead of installing the OJI plugin from the JRE installer, why don't we 
install the OJI plug-in through the XPI. Thus, when the XPI is launched, it 
will launch the JRE installer. Once completed, then it will copy all the 
NPJPI*.dll and NPJava*.dll into the plugins directory according to

       key:  HKEY_LOCAL_MACHINE\Software\JavaSoft\Java Runtime 
Environment\[CurrentVersion]
       name: JavaHome

      Since the XPI always know what version of JRE it bundles, so it can do
a much better job to pick up the right JRE and install it into the right 
location.

One of our embedding vendors asked me what that status of this bug is?
I have a patch for the temporary work around being reviewed.

I will try Stanley's suggestion afterwards.  There might be a problem with 
xpinstall performing a launch-and-wait on the jre32i.exe installer.
*** Bug 55757 has been marked as a duplicate of this bug. ***
cc:ing Marek
is bug 62324 a dup?
Keywords: mostfreq, nsCatFood
No, this bug is for windows platform. Bug 61049 marked as dup of 62324.
*** Bug 62324 has been marked as a duplicate of this bug. ***
Can somebody please set the OS to All again? New bug reporters will probably not
find this bug when it is marked as an NT bug.
Just set it to 'all' - especially since I first noted the bug on Win98 SE!
OS: Windows NT → All
*** Bug 62324 has been marked as a duplicate of this bug. ***
Argh! I'm gonna close this one invalid to force new bugs if we don't start 
making some sense here. It does absolutely ZERO good to clump similar but 
actually different bugs into the same report.

Resetting to windows OS, re-opening 62324 for Linux. Note the comments from SSU 
indicating this would be improved by an installer fix, which is extremely 
platform specific.
OS: All → Windows NT
Hardware: All → PC
Summary: Mozilla fails to detect installation of JRE plugin → [Win32]Mozilla fails to detect installation of JRE plugin
Alright, aquiescing.  If anyone wants to start blaming the installer 
again please write a NEW bug specific to the platform and mark this bug blocked 
by it.
OS: Windows NT → All
Hardware: PC → All
Summary: [Win32]Mozilla fails to detect installation of JRE plugin → Mozilla fails to detect installation of JRE plugin
Xiaobin, can you please summarize the status of this bug?
  I think it's good to mark this bug as ALL to make people easy to find the bug.
Anyway, I am owning the bug both in Linux and windows. 

ssu:
  BTW,how's your patch? Can you post it to here? Thanks in advance!

Xiaobin 
well the patch was part of another fix which just got checked in last night.  So 
today's mozilla build should have this fix.

Mozilla installer re-registers:
key: HKEY_LOCAL_MACHINE\software\Mozilla\Seamonkey\[us]\Main
name: Install Directory
With today's build, the plugin is installed correctly, but it requires a restart
of mozilla before it works (and it doesn't tell me that).  Also, the download
dialog comes up empty (it doesn't list the plugin it's going to download, but
asks me to confirm an empty package list).  Not sure if either of these problems
are covered by this or other bugs.

Also, Java doesn't work in commercial release builds -- the java2 directory is
there but the library and the symlink aren't put into the plugins directory. 
That's a commercial build issue, though.
>with today's build, the plugin is installed correctly, but it requires a 
>restart of mozilla before it works (and it doesn't tell me that).

javascript:navigator.plugins.refresh(1) should enable the plugin without 
restarting Mozilla.
av:
   Do you mean at the final step of installing plugin, we need to call 
navigator.plugins.refresh(1)? 
  
That's a possibility. Otherwise, it will not be seen by Mozilla. I am not sure 
if the installer can register the plugin with the component manager. If it can, 
this could be another possibility.
Sean:
   Can the installer do that registration thing? If the browser does not need 
to restart to make java plugin work, it will be nice.
akkana: the blank dialog text is a different problem

xiaobin.lu: the install script can do a refreshPlugins() *AFTER* the 
performInstall() step, and you should only do so if the result is 
Install.SUCCESS

refreshPlugins() is a new feature so if your .xpi package is intended for a 
mixture of old and new mozilla/netscape versions you should test to see if its 
defined before calling it or be prepared to catch an exception. Otherwise it 
will abort the install script. I supposed aborting at the end isn't so bad, 
except the wrong error will be returned to the launching webpage if a callback 
is defined.
Dan, I think xiaobin.lu is referring to the jre.xpi that we host via 
netscape.com that rafael wrote.  All it does it launch jre13i.exe and quits.

And that's the problem.  It does not wait until jre13i.exe finishes before 
quitting.  This makes the call to refreshPlugins() irrelavent because the 
plugins are copied by jre13i.exe.

One solution would be to create a .xpi file just for the plugin files that are 
to be installed into the mozilla's (netscp6's) plugins folder.  This new .xpi 
file can be run before the launching of jre13i.exe.

The jre.xpi case is exactly the reason we added the blocking feature to 
Execute().

Passing an extra arg to Execute() won't hurt old versions of Moz, but you'd 
still want to watch out for refreshPlugins().

   Execute("jre13i.exe","",true);
 I still can reproduce this bug with the latest nightly build. Can anyone 
confirm this for me? Thanks!
This works nicely on linux commercial build 0409...but i had seen this on 
mozilla build. will verify ...
Thanks, Shrirang!
Xiaobin, once you get your linux system up, please verify this bug.
this is working fine on linux trunk (commercial and mozilla) 0410 builds. The 
java plugin installs and loads applets after I restart the browser. However, 
this is not fixed on windows mozilla build(0410)
Shrirang:
    I still can see this bug with today's trunk build both on Linux and 
WIndows. I am using RedHat 7.0 and Win NT. 

Sean:
   Would you mind updating the status of the bug? Appreciate your work very 
much! We need this work ASAP. 


I have fixed this under windows already.  How are you attempting to verify this 
bug under windows?  what are your steps?

Also how are you verifying this bug under linux?  what are your steps?

(it would be much simpler to have a seperate bug for each platform.  this will 
get really confusing, if it's not already)
also please include the full urls of where you found the builds you are testing 
with.
For Windows paltform:
   I tried two ways: One is downloading the mozilla daily build ( binary) and 
visit java.sun.com. It prompts me to download the plugin and I install it. 
After finishing, quit the browser and restart, go to java.sun.com and it still 
prompts me to get the plugin.
   The other way is to build the trunk. Following the same step above, still 
doe not work.

Shrirang: I made a mistake. I am testing it with my debug build and I will see 
if it works with my non-debug build. 

   Thank you guys very much!
   Testing with today's build in Windows and Linux, both works. By the way, in 
windows now it seems that we need to restart the machine to make it work.

I mean both works with non-debug build.
So will this now work, even for our embedding partners?
Apparently until the JRE installer is changed embedding partners will have to 
masquerade as Mozilla\Seamonkey (or Netscape\Netscape6) in the windows registry 
in order to be found by the JRE.
I have a feature I implemented that may help:

http://bugscape.mcom.com/show_bug.cgi?id=3863
Since this bug has been solved, I would like to close this bug soon. Please let 
me know if there is any problem exists.
I just got the latest nightly build (2001042013) and installed the java plugin
off my disk as root twice and once as a normal user. I restarted mozilla and
went to java.sun.com each time, it crashed every time. I then removed the plugin
and went to java.sun.com and it crashed the same way. Then I removed it and
re-extracted it, I went to java.sun.com, it crashed the same way again. My guess
is that build 2001042013 has some other error that's causing the problem. 
Eric:
   Are you testing it in Linux? What's the version of Linux are you using?
that is bug 75070
RedHat Linux 6.2.
*** Bug 72472 has been marked as a duplicate of this bug. ***
  I think the problem Eric reported is a duplicate of bug 76291.


Ops I mean it is dup of bug 76921.
ok, sorry
I still had the same problem today on the 0.8.1 (2001041212) build and the most
recent build (2001042504). These are both on w2k. 

I had JRE installed on my machine, removed the current mozilla version by
deleting all files from the program files\mozilla\bin directory then installed
again from the mozilla-win32.zip to this now empty directory. The JRE will
download and install (again) but it will not register.

Copying the npoji600.dll to the plugin directory and then restarting mozilla
solved the problem.

Will this be fixed any time soon?
The installer needs to put the DLL in the right location on Windows. Arun, 
what's the other bug about plugin installer issues?
Finding our install location doesn't sound like a challenging fix -- hope it's 
ready soon :-)  peterl, the bug you're probably thinking of is Bug 35916 .  It's 
pertinent to Macromedia, and is the only installer issue on my radar.  Once 
again, it's a case of an installer looking for the wrong *.exe.  Are there other 
installer issues I ought to know about?  Let me know!
  ssu:
     I read your comment of Ari 4 again and I found the solution is really good.
( The solution is:
   Create a .xpi file just for the plugin files that are to be installed into 
the mozilla's (netscp6's) plugins folder.  This new .xpi file can be run before 
the launching of jre13i.exe.
).
  
   It seems that we can totally get rid of these registry keys. For embeded 
partners, it is a good thing. We don't need to have additional registry 
key.        
  Do you have any plan to implement this .xpi file?

  
ok i've gotten it to sorta work on linux using today's build (20010425).  but we
still have a crashing problem.

a side note: the jre.xpi file from netscape's ftp doesn't work.  i download it
to my HD, pointed my browser to it, got asked if i want to install, clicked ok.
 the next window sits there for a minute, disappears, and nothing happens.

my procedure:
1) download the JRE self extracting package from java.sun.com.
2) run and extract it into $MOZILLA_HOME/plugins.  you'll have a big tree of
files based at a directory called something like $MOZILLA_HOME/plugins/jre1.3.0_02.
3) rename this jre directory to 'java2'
4) ln -s java2/plugin/i386/ns600/libjavaplugin_oji.so .
5) visit java.sun.com.  mozilla will appear to freeze.  just wait - it's loading
the plugin.  the little java applet to the right actually works.

the problem:
if, after visiting a page that has a java applet embedded in it, you then try to
visit another page, mozilla crashes with a segfault.  not good.  it seems as
long as the plugin is never actually _loaded_ then it is ok.  so is this a
problem with mozilla, or with the jre plugin itself (haven't tested it with the
latest release of netscape6).

Brian: I believe that the crash you're experiencing is marked as Bugzilla bug 
76936.  Please check there and see if it describes the crash problem you're now 
seeing.  The crash problem is not this bug, as far as I know.
   As this bug has been resolved at least for the commercial build. All the 
embed partners can go to bug 77244 to find the progress. I would like to reopen 
this bug if problem happens again in the future. 

Shrir:
    Is that OK to close this bug? 
Xiaobin, yes, works on windows and linux trunk builds for me (0425). Pls close 
it so that I can mark it verified.
  Fixed!
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
On RedHat 6.2 build 2001043014 using the way mentioned by Brian (above) it
totally ignored the plugin. Then I tried doing it the way mozilla wants me to.
It still totally ignored the plugin. Is it me or is it Mozilla?
Eric: The Linux bug is not this bug. This bug has been marked as FIXED. I don't
know where the Linux bug is tracked, maybe 76435 will find a champion. Please
vote for that bug. As a stopgap solution, compile your Mozilla with
  ac_add_options --disable-debug
in your .mozconfig
Bug 62324 which seems to be the main Linux bug has been marked a dup. of this
bug. So which bug should I metion my problem to?
Eric:
   Actually right now the debug mozilla does not work with non-debug build of 
JRE in Linux. Only non-debug build of mozilla work with non-debug build of JRE.

That's basically true of all components, unless someone has scrupulously 
written their plugin/component without using any calls into Mozilla 
libraries/components
Dan: Is it not a serious and up to now unaddressed bug that Mozilla does not
detect the mismatch of a plugin/component's and it's own status as
debugging/non-debugging binary? I'd say any installation routine should know
about it and should stop attempting to finish an installation as soon as it
detects this mismatch. Would you file a new bug for that? Or maybe this is
already filed?
So, is there a debug build of the JRE?
** pls note**  that this bug is only fixed on the commercial builds (windows 
linux). I still see it on mozilla build on linux. Are we tracking it in 76435 or 
where?
Eric:
   Debug build of JRE is not available outside of Sun, the code is proprietary.

FYI, based on the last postings here I have filed a new bug for the problem. ID
is 78543.
verified fixed on the trunk linux/windows 0503
Status: RESOLVED → VERIFIED
Blocks: 75664
Also see bug Bugzilla Bug 78150 [RFE] Include OJI plugin installation path in 
plugin scan. A temporary, pref controled, hack to pull the Java Plugin from it's 
 installed path.
Just checked 0.91 on W2K. problem still exists. The dlls are not getting copied
into the plugins folder. BTW 0.91 is really kickass but we have to make the java
install a no brainer otherwise its not much use in a corporate environment. 
Suggesion:Till this is fixed why don't we have  a build which comes with the
Java plugin as default so we can just point it to people who want to work with
Java rather than have to monkey around with dlls.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
 How did you install the mozilla? Currently only if you install mozilla using 
mozilla installer, then Java plugin install will be ok. Please refer my comment 
at 84463 for more detail. 
  About bundling JPI with mozilla, there is already open bug for it and there is 
some gaps between Netscape folks and Sun Java plugin team.
No I did not install mozilla using the installer I used the zip file install.
  Using unzip is not a good way to install mozilla if you want to make Java 
plugin work after downloading it. Please try to use installer. Please let me 
know it is OK, then I will close the bug. 
As I understand it, the problem is that Mozilla is missing (or has the wrong)
info in the Registry re JRE components. I, too, have been using the .ZIP
download of Mozilla and only recently started using the .EXE and letting it
install over the top of the previous copy.

My question: If you "install" the .ZIP version, then manually copy the
appropriate .DLLs to the PLUGIN directory, why can't Mozilla recognize the
situation and fix it? Basically, if the HTML calls a Java applet, and the
PLUGINS are there but not the Registry info, then Mozilla should do whatever
process the .EXE installer would have done to locate the JRE and update the
required Registry entries.
 The problem of using zip is that installation method does not put registry key 
of mozilla to the machine. So Java plugin does not know where to put these dll 
files. This is why it does not work after you downloading JPI. Also, as I 
know, there are some open bugs which hinder the installer to search JRE install 
directory.
The mozilla home page is linked to the Windows zip install and not the exe.
There fore from an end user perspective this is the install that will be used
most commonly, so I think we can expect more bug reports if we mark this as closed.
BTW the method of copying the dlls after install does work(you have to restart
moz) for me on Win2K its just that I don't think the average user is savvy
enough figure this out. Infact from what I've seen the first time they come
across something that doesn't work, its immediately back to IE. Not everybody
has the curiousity bug to to figure out what got fscked.
Tony and others:
This if fixed with bug 78150. Try setting this pref and repeat your experience:

pref("plugin.do_JRE_Plugin_Scan",true);

Should be work better. If not, note in that bug.

This bug is only in Mozilla. Netscape's installer does a similar trick to locate
java and copy the DLL's. The feature in bug 78150, does not copy but does it in
real-time.

I also don't think the dependacy on bug 75664 is no longer valid.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Yeah, it ain't working. Even after uninstall-reinstall
qa->pmac
QA Contact: shrir → pmac
Keywords: mostfreq
Nathan, can you confirm this bug to see it works ok now please? I just downloaded
the commercial build from
ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/2001-08-29-11-trunk
and installed from fresh. I chose "recommend" install. This option does not include
"java-plug in supposely". However, after the installation, select Tasks > Tools
> Java Console, it pops up the Jav console windows as "Java(TM) Plug-in: Version
1.3.0_01
Using JRE version 1.3.0_01 Java HotSpot(TM) Client VM
User home directory = C:\WINDOWS

Proxy Configuration: Browser Proxy Configuration
". I expect this Java console windows 
will not pop up though. Because of this, follow your steps of how to reproduce 
this bug in step #4, I could not see the JRE install button since the JRE is 
already installed it. Anyway, correct me if I'm wrong please. I'm quite new to
this area. Thanks!
I've seen two unconfirmed bugs that look like that one in the past week.
Can someone check is this should be reopened?
I am talking about bug 100580 and bug 100316.

bug 100580 has been confirmed
Verified on windows 98 (branch build: 2001-10-01-05-0.9.4) using JRE version 1.3.1
Status: RESOLVED → VERIFIED
Could we also get a verification on Linux?  I tried it with today's branch
build, and the plugin wouldn't download -- the progress bar got about 2/3 of the
way there and then went away, replaced by a new browser window which said:

Install Results
Java 2 Plug-in for Linux: 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/jre13i.exe
for Windows. Please e-mail ftp-plugins@netscape.com if you continue to have
problems. Error encountered -- -228

(Why does it point me to a Windows file when I'm downloading the plugin for Linux?)

This was repeatable (same thing happened twice in a row).
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Marking fixed so it will show up on Linux verification radar.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Verified on windows 98 and linux redhat 6.2 (branch build: 2001-10-09-10-0.9.4). 
For this bug, it's already fixed. For other issue, please open a new bug. Thanks!
Status: RESOLVED → VERIFIED
*** Bug 70856 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: