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/

Changed to OJI. Marking NEW as per comments.

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).

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?

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

I see this on linux definitely...

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.

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.

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!

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?

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!

*** 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.

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.

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!

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

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.

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.

Yeah, it ain't working. Even after uninstall-reinstall

qa->pmac

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

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).

Marking fixed so it will show up on Linux verification radar.

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!

*** Bug 70856 has been marked as a duplicate of this bug. ***