on WinNt4.0, with seamonkey 1999091608 steps to reproduce: 1. install jre 2. launch seamonkey. 3. load the url, http://kaze:8000/javademo.htm. result: Applet fails to run. Applet contains Japanese characters. This works with Communicator 4.7.
The URL should be http://kaze:8000/javademo.html not http://kaze:8000/javademo.htm This is a Java problem. I am not sure which Component to assign to. Reassign to Java API to WebShell for now.
who is working on Java ? Reassign this to chofmann
teruko, you'll have to put the test case on mozilla or send to George Drapeau <george.drapeau@eng.Sun.COM>
I think we should make some new applets with JDK 1.2 compatibility. Most of these applets have been made for 1.02 and only a few for 1.1. Who know what classes have been deprecated since then?
I'm re-assigning this bug to Ed Burns, the module owner for WebShell (in our group). Thank you for assigning this to me. If you have any test data that we can use to reproduce the bug, I would much appreciate it.
Can you please make the applet available on the Internet.
Let me suggest 2 applets which have been externalized to public sites as part of a papaer read by Frank Tang at a Unicode conf a few years back. He has 5-6 examples but because of outdated links, only a couple seem to be working now: http://people.netscape.com/ftang/paper/unicode9/page0007.htm and http://people.netscape.com/ftang/paper/unicode9/page0027.htm You need to have a font which includes Japanese glyphs for these pages. Also as these applets were based on JDK 1.02, deprecated font names are used. For this reason, you need to modify the font.properties file to turn on font aliasing as follows: alias.timesroman=serif alias.helvetica=sansserif alias.courier=monospaced
If you are in need of Windows Unicode font, we have externalized Bistream Cyberbit 2.0 at: ftp://ftp.netscape.com/pub/communicator/extras/fonts/windows/ get the Cyberbit.ZIP file. I have a modified font.properties file with this font here: http://home.netscape.com/eng/intl/docs/jdkfont/nt4/font.properties you can use this as an exmple to modify your settings. Also I have externalized more general info on this here: http://home.netscape.com/eng/intl/jdkfontinfo.html
Here's the stack trace: stantiateFullPagePlugin.. returning InstantiateEmbededPlugin for application/x-java-vm InstantiateEmbededPlugin find stopped Document http://people.netscape.com/ftang/paper/unicode9/page0007.htm loaded suc cessfully Document: Done (3.184 secs) java.security.AccessControlException: access denied (java.net.SocketPermission j ava.sun.com resolve) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkConnect(Unknown Source) at sun.plugin.protocol.jdk12.http.HttpURLConnection.connect(Unknown Sour ce) at sun.plugin.protocol.jdk12.http.HttpURLConnection.getInputStream(Unkno wn Source) at java.net.HttpURLConnection.getResponseCode(Unknown Source) at sun.applet.AppletClassLoader.getBytes(Unknown Source) at sun.applet.AppletClassLoader.access$100(Unknown Source) at sun.applet.AppletClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.applet.AppletClassLoader.findClass(Unknown Source) at sun.plugin.security.PluginClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.applet.AppletClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.applet.AppletClassLoader.loadCode(Unknown Source) at sun.applet.AppletPanel.createApplet(Unknown Source) at sun.plugin.AppletViewer.createApplet(Unknown Source) at sun.applet.AppletPanel.runLoader(Unknown Source) at sun.applet.AppletPanel.run(Unknown Source) at java.lang.Thread.run(Unknown Source)
After making the modifications to my workstatation to accomodate SUN's firewall policy, as suggested in http://bugzilla.mozilla.org/show_bug.cgi?id=1577 , I have retested this bug and found that it now no longer manifests. To verify, please use a Java Plugin from 10/14/99 or later. Any attempts to verify using an earlier version of the Java Plugin will be summarily rejected.
*** Bug 13445 has been marked as a duplicate of this bug. ***
Questions: 1. When you say "Java Plugins later than 10/24/99", you don't mean what we get internally at Netscap,do you? For example, I tried the latest beta version available at JavaSoft and they generally work and we can see that problem applets actually run. But our internal JRE 1.2.2 distribution has not been updated since 9/15/99 or so. So, are you refering to the JRE 1.2.2 or 1.3 Beta? 2. Now that these applets more or less run, we can see the real problem for i18n, i.e. that strings do not show correctly in Japanese and other multi-byte languages. In our internal tests, there are still a few applets that will not run but these can be dealt with in this bug. For the display problem, we should file a separate bug, which is what I will do now.
The Japanese (and other non-ASCII languges) display bug has been filed as Bug 17169.
Please talk to cyeh to get a more recent version of the JDK.