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)
Tracking
(Not tracked)
VERIFIED
WONTFIX
M16
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)
Updated•25 years ago
|
Summary: Mozilla fails to launch on Japanese systems → [dogfood]Mozilla fails to launch on Japanese systems
Comment 1•25 years ago
|
||
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.
Updated•25 years ago
|
Assignee: ssu → leger
Component: Installer → Browser-General
Updated•25 years ago
|
QA Contact: gbush → leger
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...
Comment 7•25 years ago
|
||
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
Updated•25 years ago
|
Component: Internationalization → OJI
Comment 10•25 years ago
|
||
reassign to OJI folks. It looks like that we didn't package the necessary Java converter w/ the JavaVM. sun.io.ByteToCharMS932.class
Updated•25 years ago
|
Status: NEW → ASSIGNED
Updated•25 years ago
|
Assignee: ftang → edburns
Status: ASSIGNED → NEW
Comment 12•25 years ago
|
||
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.
Updated•25 years ago
|
Whiteboard: [PDT-]
Updated•25 years ago
|
Assignee: edburns → cyeh
Comment 13•25 years ago
|
||
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.
Comment 14•25 years ago
|
||
I forgot to mention the other possibility, which is to use the International version of JRE1.2.2 which contains the necessary i18n.jar.
Comment 15•25 years ago
|
||
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.
Comment 16•25 years ago
|
||
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...
Comment 19•25 years ago
|
||
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...
Comment 20•25 years ago
|
||
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.
Comment 21•25 years ago
|
||
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.
Comment 22•25 years ago
|
||
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.
Comment 23•25 years ago
|
||
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. :-)
Updated•25 years ago
|
Target Milestone: M12 → M13
Comment 24•25 years ago
|
||
moving tvf to m13. if cyeh gets the drop for putting in the installer or making available we will look at packaging in m12.
Comment 25•25 years ago
|
||
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?
Comment 27•25 years ago
|
||
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?
Comment 28•25 years ago
|
||
If we are packaging JRE1.3 beta now, why is it that the file is named jre122.exe in the xpi directory?
Comment 29•25 years ago
|
||
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.
Comment 30•25 years ago
|
||
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.
Comment 31•25 years ago
|
||
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
Comment 32•25 years ago
|
||
petitta and ssu updated the components a while ago. alan, can you verify if this bug is fixed or not?
Reporter | ||
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Reporter | ||
Comment 33•25 years ago
|
||
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
Updated•25 years ago
|
Resolution: FIXED → ---
Comment 34•25 years ago
|
||
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
Comment 35•25 years ago
|
||
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!
Comment 36•25 years ago
|
||
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?
Reporter | ||
Comment 37•25 years ago
|
||
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.
Comment 38•25 years ago
|
||
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.
Assignee | ||
Comment 40•25 years ago
|
||
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.
Comment 42•25 years ago
|
||
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
Comment 43•25 years ago
|
||
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.
Reporter | ||
Comment 44•25 years ago
|
||
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 → ---
Assignee | ||
Comment 45•25 years ago
|
||
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.
Comment 46•25 years ago
|
||
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
Assignee | ||
Comment 47•25 years ago
|
||
Please note that PAW has the latest JRE, but Java still doesn't work in mozilla. Also, this problem cannot be replicated on WinNT.
Comment 48•25 years ago
|
||
Need to get the installer updated.
Whiteboard: [PDT+]RN → [PDT+]RN February 11th
Updated•25 years ago
|
Keywords: dogfood
Summary: [DOGFOOD]App crashes in Java at launch on Japanese systems → App crashes in Java at launch on Japanese systems
Comment 49•25 years ago
|
||
I have the new jre in my hands, i'll get with ssu about getting it into the installer.
Status: NEW → ASSIGNED
Comment 50•25 years ago
|
||
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
Reporter | ||
Comment 51•25 years ago
|
||
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.
Comment 52•25 years ago
|
||
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.
Comment 53•25 years ago
|
||
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
Comment 54•25 years ago
|
||
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
Comment 55•25 years ago
|
||
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.
Reporter | ||
Comment 56•25 years ago
|
||
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
Reporter | ||
Comment 57•25 years ago
|
||
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.
Comment 58•25 years ago
|
||
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
Assignee | ||
Comment 60•25 years ago
|
||
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.
Comment 61•25 years ago
|
||
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.
Assignee | ||
Comment 62•25 years ago
|
||
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-.
Comment 63•25 years ago
|
||
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.
Assignee | ||
Comment 64•25 years ago
|
||
I've created a new bug, as momoi suggested, 30096. They are really two different views of the same bug.
No longer blocks: 30096
Comment 66•25 years ago
|
||
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.
Comment 67•25 years ago
|
||
This sounds fixed... but all that was asked for was a PDT-...
Whiteboard: [PDT-]
Reporter | ||
Comment 68•25 years ago
|
||
I don't know how the PDT- got there, but International has always viewed this as a beta stopper.
Comment 69•25 years ago
|
||
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.
Reporter | ||
Comment 70•25 years ago
|
||
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.
Assignee | ||
Comment 71•25 years ago
|
||
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
Assignee | ||
Comment 73•25 years ago
|
||
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
Comment 75•25 years ago
|
||
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.
Comment 76•25 years ago
|
||
this is M16, but it seems fixed. can anyone vrfy?
Severity: major → critical
Comment 77•25 years ago
|
||
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
Comment 79•25 years ago
|
||
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.
Comment 80•25 years ago
|
||
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. "
Comment 81•25 years ago
|
||
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 → ---
Comment 82•25 years ago
|
||
I do not understand the issue. I changed QA contact to momoi@netscape.com.
QA Contact: teruko → momoi
Assignee | ||
Comment 83•25 years ago
|
||
Reassigning to Raju so he can test when he gets his Japanese system installed.
Assignee: edburns → rpallath
Status: REOPENED → NEW
Comment 84•25 years ago
|
||
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-]
Comment 85•25 years ago
|
||
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
Comment 86•25 years ago
|
||
M16 has been out for a while now, these bugs target milestones need to be updated.
Comment 88•25 years ago
|
||
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.
Comment 89•25 years ago
|
||
Ed, I'm reassigning this bug back to you. The problem still occurs. It crashes when there is no i18n.jar.
Assignee: rpallath → edburns
Comment 90•25 years ago
|
||
Workaround being provided in the Win32 Java Plug-In by Stanley today.
Whiteboard: [nsbeta2+][dogfood-] → [nsbeta2+][dogfood-] STANLEY_WORKAROUND
Comment 91•25 years ago
|
||
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 → 25 years ago
Resolution: --- → FIXED
Updated•24 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 92•24 years ago
|
||
** 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: 25 years ago → 24 years ago
Resolution: --- → WONTFIX
Assignee | ||
Comment 93•24 years ago
|
||
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.
Comment 94•24 years ago
|
||
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
Comment 95•24 years ago
|
||
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?
You need to log in
before you can comment on or make changes to this bug.
Description
•