I tested 4-8-10-99 Win32 build under Winnt4.0J and Windows 95J. This happens under Windows 95J. When I go to the Korean page http://home.netscape.com/ko and both Simplified Chinese and Traditional Chinese page http://home.netscape.com/zh, Apprunner will crash. Under Winnt 4.0J, it does not crash.

I tested these page under Win98J. Apprunner does not crash.

Under Windows 95J, Apprunner will crash when loading some Japanese pages. http://babel/tests/browser/bft/sjis/bft_browser_form_sjis.html or other HTML test cases under http://babel/tests/browser/html/new_html40/sjis/ directory. but Apprunner does not crash when loading http://home.netscape.com/ja page. Under Windows 95US and Windows 95Korean, Apprunner does not crash in Korean and Chinese Netscape home pages.

Here's one workaround for this problem. For Japanese display only, you can download the prefs.js file from here: http://rocknroll/users/momoi/publish/ and have Bitstream Cyberbit font on your system. You should not modify or comment out the default charset line: user_pref("intl.character_set", 260); Plus of course the font settings. This takes care of the following problems: 1. Proble pages like the follolwing will load without an error and displays OK. http://home.netscape.com/ja http://Kaze:8000/jis.html http://kaze:8000/sjis.html http://kaze:8000/euc.html This probably means that Korean and Chinese display will not work all that well. 2.Windows-native fonts will not let you display Japanese. Bitstream font setting in the prefs,js file makes it OK.

OK, I tracked this down. If you call GetTextExtentPoint32W on the character 0xB7 in the Times font on Japanese Windows 95, you crash. It also crashes if the character is 0xFFFD. Unbelievable. Any suggestions to workaround this?

I wrote a tiny program to check this, and it does indeed crash on 0xB7, but not on 0xFFFD. However, Mozilla does crash on 0xFFFD sometimes. I also tried GetTextExtentPoint32A on 0xB7 on Japanese Windows 95, and it did not crash. Sigh. Does this mean that we need to convert from Unicode to the various code pages before calling the Windows APIs on Windows 95?

This need to be reopened since 4810 is reopened.

I found the bug, and fixed it in my local tree.

Putting on QA Blocker List.

I verified this in Win32 5-03-08 build under Win95J.