Closed Bug 21305 Opened 25 years ago Closed 24 years ago

App crashes in Java at launch on Japanese systems

Categories

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

Product:
Core Graveyard
Component:
Java: OJI
Platform:
x86
Windows 98
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX

People

(Reporter: amasri, Assigned: edburns)

References

Details

(Keywords: crash, relnote, Whiteboard: [nsbeta2+][dogfood-] STANLEY_WORKAROUND) 

with win98ja, mozilla 1999120815:

Mozilla commercial build fails to launch. DOS window stops after line:

nNCL Registering deferred (0)
Summary: Mozilla fails to launch on Japanese systems → [dogfood]Mozilla fails to launch on Japanese systems
This is not same bug as 19165.  msvcirt.dll's version is 6.00.8168.0 and msvcrt.dll's version is 6.00.8337.0.
Whiteboard: [PDT+]
Putting on PDT+ radar.
Assignee: ssu → leger
Component: Installer → Browser-General
This is not an installer bug if you get the mozilla console.
QA Contact: gbush → leger
changing QA contact from Installer
QA Contact: leger → amasri
changing qa contact to amasri
Just as an FYI: I was able to get the 1999120908 Mozilla build working
successfully on this machine. There is virtually no free hard drive space on it
so perhaps the issue had something to do with the installer not installing all
the files, or a low-memory situation, or something... still investigating. There
is also a Windows 95 machine in the same cube that won't start Mozilla, but I
have a hunch that may be related to bad video drivers (it can only display 16
colors right now and is spewing errors about bad video driver setup). I'll keep
working on it and report back...
Chris and I tested 120908 Win32 build.
The error in the Dos prompt window says "Error occurred during initialization of VM
java/lang/ClassNotFoundException: sun/io/ByteToCharMS932".

When we rename dll under plugins directory (which is subdirectory of Seamonkey) to something else,
Mozilla.exe will launch.
CC'ing edburns@acm.org, one of the Java guys.  Are we missing this class?
Summary: [dogfood]Mozilla fails to launch on Japanese systems → [DOGFOOD]App crashes in Java at launch on Japanese systems
In order to successfully launch the commercial build on a Japanese machine, you
must remove or rename the three Java plugins in the \plugins directory. If you
don't, the app will crash. Either teruko or amasri should be able to provide
further details (I don't have a Japanese language machine here).
Assignee: leger → ftang
Component: Browser-General → Internationalization
Component: Internationalization → OJI
reassign to OJI folks. It looks like that we didn't package the necessary Java
converter w/ the JavaVM. sun.io.ByteToCharMS932.class
Status: NEW → ASSIGNED
Whiteboard: [PDT+]
This does not appear to be a PDT+ bug. Demoting.
Assignee: ftang → edburns
Status: ASSIGNED → NEW
the JRE 1.3 installed do not have lib/i18n.jar . According to Brian Beck
<bcbeck@eng.sun.com>, the Shift_JIS to Unicode converter sun.io.ByteToCharMS932
is needed for Japanese win 95/98 system.
now this become an installeration issue. the i18n version of JRE 1.3 have this
big i18n.jar there. But we are currengly packaged with english version which do
not have this i18n.jar file. Also the size of the english one is 4+M but the
i18n one is 7+ M (after compression...)

I suggest we do the following
1. put i18n.jar as a seperate package and allow user to download
2. In installer, if user want to install JRE and the system is non English
version ( ::GetACP() != 1252 ) , require that i18n.jar get installed.
3. Change JRE code to be graceful when JRE cannot be startup.

reassign to JRE folks.
Whiteboard: [PDT-]
Assignee: edburns → cyeh
Re-assiging to cyeh@netscape.com.

Chris, we talked about this before.
We are currently installing JRE1.2.2 which does not
contain the necesary i18n.jar to avoid this crash on Win98-J.
If you decide to go with JRE 1.3(beta), then we need the
i18n.jar which comes with the International verison of
JRE1.3. (It does not come with the non-international version
of JRE1.3.)

People who get JRE1.3 beta as part of JDK1.3 beta should not
have this problem because such a package includes JRE1.3 with
i18n.jar.

At minimum we need to release note this for Win98-J users.
I forgot to mention the other possibility, which is to use
the International version of JRE1.2.2 which contains the necessary
i18n.jar.
Hi, momoi@netscape.com.  I'm commenting on your last comment, that one option is
to get the JRE 1.2.2 International version which contains the necessary I18N
jar.  My comment is this: it's cool to get the I18N jar file and put it with the
1.3 JRJ, but the 1.2.2 JRE itself won't work with current Mozilla builds.  The
1.2.2 Java Plug-In was written months ago, and Mozilla API's have changed then,
so run-time linkage of the JPI shared library won't work.  If you use the JRE
1.3, and add the I18N jar file, you should be okay.
Whiteboard: [PDT-]
Removing PDT- for new Dogfood consideration (actually this is an M12 stopper);
it crashes in JA systems and we need the right files installed to avoid this
crash...
Whiteboard: [PDT-]RN
Putting on PDT- radar.  Will release note for dogfood to turn off Java.
Chris, can you mark a TFV for this bug? Thanks.
Target Milestone: M12
The only workaround is to remove the Java plugins from the plugins directory;
turning off Java is not a possibility (build never starts).

I really think this should be fixed; any Japanese installed on Win 98 and
probably Win 95 (we have another crash now that prevents us from trying this one
21352). I can imagine what problems we are going to have with
Japanese downloads...
Hi, all.  I'd like to help if I can, but I could use some clarification on the
last few comments in this bug report.  In momoi's comment of 1999-12-10 18:43,
it sounded like things will work as long as you use the JRE 1.3 Beta (or Early
Access), since it includes the necessary I18N.jar.

But a later comment by leger (12/14/99 17:39) says "will release note to turn
off Java."  I missed something there; if the JRE 1.3Beta works fine, why turn
off Java?

A later comment by msanz (12/14/99 18:12) said "...turning off Java is not a
possibility (build never starts)."  I didn't understand that comment: why can't
you build the browser if you "turn off java"?  What does it mean to "turn off
java"?

I'm happy to try and help fix, and I can alert the JDK folks at Sun to any
problem they need to address (although it seems from the bug report that you all
have that covered already), but I think my brain is fried and I'm just not
getting some of this.

The last comment by msanz says "I really think this should be fixed...", with
which I agree.  But from earlier in the bug, it sounds like the fix is to get
the JRE 1.3 Beta.  I've got to be missing something, right?

Sorry for the intrusion.  If this is none of my business, I apologize for the
extra cruft in this bug report.
Hi, what I meant by "...turning off Java is not a possibility (build never
starts)" is that this is not a crash that happens after the build is launched,
but right at launch time. In any case, we agree. I'll let Chris Yeh explain why
this fix may not be possible for M12.
Status: NEW → ASSIGNED
Okay, in reading the bug report, I understand the situation to be thus:

Mozilla doesn't work with anything other than 1.3 Java JRE.
1.3 Java JRE contains necessary i18n jar to prevent crashes.

So unless I'm missing something really important, the right thing seems to be to
just bundle the 1.3 Java JRE. I was cool to this idea initially, since there is
some question in my mind about bundling a beta JRE with our beta (call me old
fashioned, but I like official shipping software and stability) and the timeline
of the beta JRE (I.E. will it be final by the time we ship SeaMonkey)

I'm going to go verify that we are shipping the latest 1.3 JRE. If we are not,
I'm going to need to get the latest drop from Sun that includes the necessary
i18n jar.

Not sure if I can make the M12 train, but I'm going to try.
That's my understanding as well, Chris.  I believe that the 1.3 JRE should be
bundled; forget about JRE 1.2.  I believe it won't work with current Mozilla
builds anyway, since the 1.2 JRE's Java Plug-In was written against Mozilla
API's of a few months ago, and those API's have changed enough to break Java
Plug-In.  The JDK 1.3's Java Plug-In works fine with current builds, though.

As to your concern about bundling a beta product with Mozilla, what can I tell
you?  JDK 1.3 is almost at FCS, but is not there yet.  Meanwhile, Mozilla isn't
even at beta yet, so it's possible that API's will change *yet again* enough to
break the current Java Plug-In (JPI uses XPCOM, and if XPCOM API's change again
after the JDK 1.3 code freeze, then JDK 1.3 may go out with a Java Plug-In that
doesn't work with Mozilla M12+.  That would suck.  Luckily, Suresh Duddi is
being nice and trying to keep as much compatibility with current API's as
possible, so that Java will continue to work.)

In any case, we're talking about bundling a post-beta JDK with a pre-beta
Mozilla.  The JDK part will be at FCS before Mozilla reaches FCS, and it's
possible that the JDK part will be at FCS by Mozilla's beta time.  I say that
for this milestone, it's okay to release the current JDK; it's better than none,
in my opinion.

Easy for me to say, though.  :-)
Target Milestone: M12 → M13
moving tvf to m13.  if cyeh gets the drop for putting in the installer
or making available we will look at packaging in m12.
I have JRE1.3 Intl Beta downloaded a few days ago
internally but we probably want an official drop from
Sun, right?
drapeau@eng.sun.com, can you provide Chris the appropriate
international verison today?
Yes, will do.  I'll send it along today.
Note: we *are* currently packaging the Beta JRE 1.3 with commercial builds--the
English version which does not have the required file. Shipping the Beta i18n
version instead doesn't sound like a big deal other than the extra 3Mb
download.

Is the only difference the addition of i18n.jar? If so perhaps we could package
that in a standalone XPI install and add it as an install menu choice, which
would then make it available to Europeans who are willing to accept the extra
download size.  If that's not a possibility we could either replace the
"english" version with the i18n version for all users, or offer both. Our
install doesn't support exclusive packages so there would not be a way to
prevent users from trying to download both in that case. We could talk about
such a feature, but it would be low priority.

For Netscape's beta perhaps shipping just the i18n version is the right thing,
we can optimize for size later.

Needless to say, crashing because of a missing Java class is a bad bug and
should be addressed apart from this packaging issue. Is it an OJI bug? A bug in
the Sun plugin or JVM? A Mozilla bug?
If we are packaging JRE1.3 beta now, why is it that the file is named
jre122.exe in the xpi directory?
Sorry, you're right. I looked in the "current/xpi" directory and saw a JRE 1.3
and didn't read any further. There is also the JRE122, and since that's the
only one in the dated directories I guess that must be the real one and the 1.3
must be yet another example of the build team not clearing old crap out of
deliverable directories before putting new stuff into them.
Regarding dveditz's comment from 1999-12-15 13:02, yes, I agree that no matter
how we take care of this, the browser shouldn't crash because of a missing Java
class.  I'll have QA on our side create a test that simulates this problem and
we can address it from there, find out where the problem is.

Leila, can you create a test that simulates this problem?  If you need help,
come talk to me and I'll explain as best I understand this situation.
any word on the fix to avoid the crash or a new drop into the installers for
m13?
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
petitta and ssu updated the components a while ago.

alan, can you verify if this bug is fixed or not?
Status: RESOLVED → REOPENED
I tried this with this afternoon's build (20000119xx). After installing the
Complete install, the problem still exists. Now, the dos window reads:

Error occurred during initialization of VM
java/lang/ClassNotFoundException: sun/io/ByteToCharMS932
Resolution: FIXED → ---
Moving to M14 per PDT mtg.  lyecies was present from i18n and agreed.  Need to 
get this release noted for M13.
Target Milestone: M13 → M14
Is this still an open issue with latest build?  If so, can you 

1) comment in bug as to build still happening
2) remove PDT- from Status Summary
3) add beta1 to keyword field so PDT can review for beta1

We'd like to make sure this gets fixed for you ASAP if still a problem..thanks!
Two comments:

1) I believe that the Java Plug-In based on JDK 1.3 will not work with current
Mozilla builds, due to recent Mozilla API changes that broke compatibility with
existing Java Plug-In binaries.  See Bugzilla bug #24487 for details.

2) I thought this issue had been taken care of in M11 or M12, that having the
JDK 1.3 solved this problem?  Wasn't the issue that an i18n.jar file was missing
in the Japanese distribution of JRE?  If that's the case, then JRE 1.3 should
solve this problem, since i18n.jar is bundled with JRE1.3 by default.

Am I missing something here?

This still fails. It may be due to Bug 24487, although the failures are 
different (see above for description). During installation, a progress window 
displays the message, "Configuring Sun JRE 1.2.2". I presume this means we are 
not installing JDK 1.3? We will need to resolve the other issues before we can 
tell if this one works or not.
I've never seen the installer, so I don't know where that message "Installing
the JRE 1.2.2" comes from.  Who at Netscape creates that installer thing?  Who
was responsible for that message?  Who is responsible for putting the JRE into
the installer thing?

Netscape has internal early-access copies of JRE 1.3.  If you have any copies
of JRE 1.2.2, you should delete them and begin using JRE 1.3 immediately.  The 
message that you're seeing about installing JRE 1.2.2 worries me.

Meanwhile, when the JDK folks at Sun have patched Java Plug-In 1.3 to work with 
current
Mozilla builds, they will give us a binary which we will then bring to Netscape 
so that all Netscape people have the latest, working Java Plug-In for testing 
Java integration with Mozilla.  I'll keep this bug apprised of progress on the 
issue.
Adding "crash" keyword to all known open crasher bugs.
Keywords: crash
I believe this is still happening in all builds, but this belief cannot be 
verified due to bug 24487.  I've marked this as depending on 24487.
Status: REOPENED → ASSIGNED
Depends on: 24487
Keywords: beta1
Whiteboard: [PDT-]RN → RN
Putting on PDT+ radar for beta1.
Whiteboard: RN → [PDT+]RN
this bug turned out to be about getting jre 1.3 packaged in the builds.
marking it fixed.  lets get it verfied when other blockers are removed.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Chris, can I take it that the JRE1.3 will get into the 
source in tomorrow's builds. The installer was still using
JRE1.2.2 and actually not installing any Java files with
2/1/2000 Win32 build installer.
with win32 build 2000020411-M14 on win98-ja:

1. SmartDownload fails (using complete install). The message in the 
SmartDownload window is: "Saving Sun JRE 1.2.2" The error message reads: "There 
is a temporary network error preventing the download of your file". Installation 
cannot recover after this error.

2. Using mozilla-win32.zip to install:

Steps to reproduce:

1. download mozilla-win32.zip
2. extract files to a directory.
3. execute mozilla.exe

Result:

Mozilla fails to launch. The splash screen appears and mozilla dies quietly, 
with no error messages of any kind.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
momoi: I hope that the JRE1.3 I gave Paul yesterday has made it into your 
internal installers.

However, when I tried that JRE with today's mozilla build, I could view no 
applets.  I tried build, one that had worked with my previous mozilla build 
from the last week in January, and I still could view no applets.  It looks 
like something has changed in mozilla to have broken applets.


Leaf...

Can you get with either the Sun folks or momoi and make sure the latest JRE 
makes it into the Win32 builds?
Assignee: cyeh → leaf
Status: REOPENED → NEW
Please note that PAW has the latest JRE, but Java still doesn't work in mozilla.

Also, this problem cannot be replicated on WinNT.
Need to get the installer updated.
Whiteboard: [PDT+]RN → [PDT+]RN February 11th
Keywords: dogfood
Summary: [DOGFOOD]App crashes in Java at launch on Japanese systems → App crashes in Java at launch on Japanese systems
I have the new jre in my hands, i'll get with ssu about getting it into the
installer.
Status: NEW → ASSIGNED
When today's verification build comes out, can someone with a windows-japanese
system try downloading and installing the jre with it?
Whiteboard: [PDT+]RN February 11th → [PDT+] today's jre 1.3 should prevent crashes
With today's build:
(1)The correct jre1.3 is downloaded, as indicated in the installation progress 
panel.
(2)The application will not launch. The splash screen displays, then the 
application exits.
I'll check this on an en system and see if i get the same thing. If i do, i'm
punting to george for this.
I don't even get loads of applets in today's windows build with the jre drop i
have. (going to http://www.javasoft.com gives me a couple of ``loading
applet...'' panes, but that's it).

I'm reassigning this to george.
Assignee: leaf → drapeau
Status: ASSIGNED → NEW
Re-assigning to Ed Burns, so that he can verify it works or not, or mark
a dependency on other bugs.  Stanley Ho (stanley.ho@eng.sun.com) has filed
several bugs in other modules that prevent Java Plug-In from working, especially
in the case that leaf mentioned in the comment just before this one.

Ed, if you don't wish to take this bug, just re-assign it to me and I'll 
continue to follow up on it.
Assignee: drapeau → edburns
I installed new JRE 1.3 in 3 Windows JA systems.
Afte JRE 1.3 is installed C:\Program Files\Netscape\Javasoft\ directory, the behaviors are following.

Win98J - The splash screen displays, then the application (Netscape 6) exits
              If you rename the Javasoft directory or delete it, the application will launch.

Winnt4.0J - Same as Win98J.
 
Win95J - The application (Netscape 6) will launch without any problems.

warren just filed bug 26516, Java/Plugins initialize at startup. This seems to 
be what is causing the trouble here. seamonkey initializes Java, which then 
crashes and prevents launch. Since Java 1.3 doesn't seem to fix the problem, one 
way to solve it would be to fix bug 26516. I marked it as a dependency to this 
bug.
Depends on: 26516
I discussed this with momoi and it seems that JRE 1.3 will work if we install the i18n.jar. When I ran jre1_3beta-win-i.exe, the proper files were installed and netscape 6 now runs fine on the Japanese system.
Must fix by 03/03
Whiteboard: [PDT+] today's jre 1.3 should prevent crashes → [PDT+] Must fix by 03/03-today's jre 1.3 should prevent crashes
Whiteboard: [PDT+] Must fix by 03/03-today's jre 1.3 should prevent crashes → [PDT+]w/b minus on 03/03-today's jre 1.3 should prevent crashes
Building with av's fix to 27486.  Will test no 02/25.
I have asked our QA guy for OJI to test this on a Japanese system.  Since this 
is Japanese only bug, can we reprioritize it?
Whiteboard: [PDT+]w/b minus on 03/03-today's jre 1.3 should prevent crashes → [PDT+]w/b minus on 03/03-today's jre 1.3 should prevent crashes. Will have results of test on real Japanese system on 02/29/00.
Tried the same on a WinNT Japanese system
Installed  Win32 installer from nightly build  dated 02/25/2000.
Installed patched in java Plugin 1.3 (with i18n.jar) from Stanley Ho  dated
02/25/2000.

Try to load the page with an applet. It does load correctly.

Renamed the i18n.jar (to some dummy name) and found that this time  
on invoking mozilla , it would exit out after the splash screen.


Raju, can you be more specific about the issues around the i18n.jar file?  That
is, where exactly must it reside, and which JRE installers include this file.

All, what Raju is saying here is that it's an installer problem.  True, it
shouldn't crash if you don't have that jar file, but I don't know if that's a
PDT+ bug, when most people SHOULD have the jar file.

I vote for changing this to PDT-.


I think we need a practical solution to this problem. 
If fixing the OJI problem is not a PDT+ bug, then we 
should separate the installer issue into another bug
and mark it PDT+ for Japanese beta. That is another 
way of looking at this issue.
Blocks: 30096
I've created a new bug, as momoi suggested, 30096.  They are really two 
different views of the same bug.
No longer blocks: 30096
Can we revise this down to PDT- please?
The crashing problem has been fixed by a new Java installer
package from Sun. See Bug 30096. The Staus whiteboard has been 
cleared since the workaround is now in place. Subimitting
for reclassification to PDT-
Severity: blocker → major
Whiteboard: [PDT+]w/b minus on 03/03-today's jre 1.3 should prevent crashes. Will have results of test on real Japanese system on 02/29/00.
This sounds fixed... but all that was asked for was a PDT-...
Whiteboard: [PDT-]
I don't know how the PDT- got there, but International has always viewed this as a beta stopper.
Is Japanese Windows still crashing on launch
when Java install option is chosen? I thought that 
Bug 30096 took care of that problem - it is now verified
as fixed. 

This will leave only one kind of case where the
fix requested here is needed, i.e. a case where the user
of CJK Windows installed a non-international version of 
Java and somehow copied the Java plugin files into the
plugin folder without using Mozilla's Java installer.

Netscape 6 no longer crashes, since it installs the JRE 1.3 + i18n.jar. Excuse 
my mistake. This bug is PDT-, since 30096 is fixed.
This is a real bug, but it only happens when the user has an incorrect JRE.  
Nevertheless, the browser should not crash.
Status: NEW → ASSIGNED
The remaining problem will be release-noted for Beta 1.
Keywords: relnote
This isn't a stability blocker, since the problem doesn't occurr if you use the 
supported Java software.  Moving to M16
Target Milestone: M14 → M16
Assigning to teruko.
QA Contact: amasri → teruko
I tested this in 2000042611 M16 Win32 build with Win98J, Win95J, and Winnt4.0J.
After I install the different version of JRE, 1.2.2,  Netscape6 did not crash
anymore.  I think this bug is fixed.
this is M16, but it seems fixed.  can anyone vrfy?
Severity: major → critical
This does not happen anymore in 5-11-09 Win32 build.  I mark as fixed.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Verified.
Status: RESOLVED → VERIFIED
I don' tknow if this has been fixed. This bug was kept open to fix cases when someone installed a
JRE without interntional component in it. I don't see that Ed has fixe this problem. 
The crashing problem would not occur right now simply because we are installing the international 
version of JRE. 
Has this really been tested against non-international version of JRE 1.3?
Please update the status. 
I do not understand why we need to test non-international JRE 1.3.
The original bug was found with JRE 1.2.2 which is not include I18n.jar.
In my previoud comment, 
"I tested this in 2000042611 M16 Win32 build with Win98J, Win95J, and Winnt4.0J.
After I install the different version of JRE, 1.2.2, Netscape 6 did not crash. "

Actually, JRE1.3 we are installing is also an international version. 
It is not for our internal purpose that this bug shoud be kept open. 
The installer issue was taken care of in another bug -- that is
why we don't have crashes any more. 
This bug is for thse cases in which some people may have installed
a non-international version of JRE.  We should keep this bug open until
that issue has been taken care of. The problem you're concerned about
has been taken care of in Bug  30096. This bug is now for a different
issue.
Re-opening until the remaining issue is resolved.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
I do not understand the issue. I changed QA contact to momoi@netscape.com.
QA Contact: teruko → momoi
Reassigning to Raju so he can test when he gets his Japanese system installed.
Assignee: edburns → rpallath
Status: REOPENED → NEW
Putting on [nsbeta2+][dogfood-] radar.  Does not need a fix ASAP for daily work, 
but we should fix this for beta2.
Keywords: nsbeta2
Whiteboard: [PDT-] → [nsbeta2+][dogfood-]
Momoi,

Can u try to see this on a Japanese system, if u have one.
I still do not have the machine with a Japanese version in place.

- raju

M16 has been out for a while now, these bugs target milestones need to be 
updated.
cc'd ftang, so he is aware of the nsbeta2+ petential Japanese crasher
Finally I did get WinNT -Japanese version set up.

Installed JDK1.3  then applied the patched version (1.3.0-netscape6-pr2).
It has i18n.jar file included.

Used M16 build and 7/14/00 nightly build
In both cases Mozilla  invokes correctly and is able to run applets.

Now I remove the i18n.jar .
And tried to invoke mozilla.
This time it  brings up spalsh screen and then puts out an error message (In
japanese and exits out.


So the bug is still holds.
Mozilla should not crash on not finding a particular class file.


Ed, I'm reassigning this bug back to you.
The problem still occurs. It crashes when there is no  i18n.jar.
Assignee: rpallath → edburns
Workaround being provided in the Win32 Java Plug-In by Stanley today.
Whiteboard: [nsbeta2+][dogfood-] → [nsbeta2+][dogfood-] STANLEY_WORKAROUND
Per chofmann "the latest java drop is in builds after friday afternoon."  
Marking Fixed to get verified with Monday builds.
Status: NEW → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
** Checked 8/23/2000 Win32 build **

The fix for this problem can be tested in the following manner:

1. Remove all prior JRE installations on Win95-Japanese.
2. Install JRE1.3 doemstic version.
3. Install all the patches provided by Stanley Ho.
4.Install a new Mozilla build.
5. Start it and see if it comes up.
6. If the startup fails in step 5, remove the Java plugin files (3 of them)
   and try restarting. If it starts up, then we still have the problem.

Internal to Netscape, you can test this by simply ding this:

1. Download the NS6 istaller.
2. Download all the XPI files but for Java, download JRE1.3exe
   file instead of JRE1.3i.exe file. Rename "JRE1.3.exe" to
   "JRE1.3i.exe".
3. Now run the installer from this local directory.
   This will install the latest Mozilla bits, JRE1.3 domestic
    and all the Java fixes.

The problem here is that if i18n.jar is missing and if the
Java plugins are installed, Mozilla will not launch.
The fix is supposed to avoid this problem, right?

Thus from this point of view, the problem is not fixed.

If this description is not correct, please write down what is
the expected outcome of the installation steps described above.

Re-opening because the original problem is not fixed.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WONTFIX
Stanley Ho has said that he's going to make it impossible for the user to NOT
have the right i18n.jar.  True, it shouldn't crash without the jar, but we're
down to the wire.  
OK. This bug was kept open because someone suggested
that even if there is no i18n.jar, it should not crash.
But if the goal has now changed, then I agree that we
don't have to keep this open. 
I'm going to mark the resolution verified because
OJI team can certainly fix other bugs insetad of
chasing this one down. 
Make sure that this one is mentioned in the Rel notes.
Status: RESOLVED → VERIFIED
Was the WONTFIX meant for 6.0 RTM or forever?  Should this be reopened and
at least marked TM "Future"?

If someone downloads the non-international JRE directly from Sun and chooses
to not install the JRE bundled with Netscape, what will happen?
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.