Tested 5-4-08 Win32 build under Winnt 4.0J. After you visit some URL in browser, Japanese characters in the IME choice window is displayed as square when you use IME to type Japanese characters in Editor. Step of reproduce 1. Launch Apprunner 2. Go to http://home.netscape.com/ja 3. Select menu Tasks| Editor to open the Editor 4. Ctrl + ~ to turn on IME 5. Type "kannji" and hit space twice to display the IME choice window Notice that Japanese characters in the choice window are dispalyed as squares If you skip the step #2 in browser, this does not happen.

I can't reproduce this. Can you give me a bit more information about what is going on. I'll leave it open for now and see if it's one of these problems that isn't 100% reproduceable.

By the way this problem occurs almost without exception on my Mail Composer window -- you don't have to go to any URL to reproduce this problem. There at least we have also an encoding menu for mail send. On the Editor window, I don't see Character set menu. Is the input charset learned from the IME itself or something like system charset?

I tested same thing under Windows95J. Japanese characters in the choice windows are displayed as garbage. I could reproduce this without going to any url in brower under Windows 95J.

I have a bug fix for this. It's a one-line change (windows only) that has minimal impact on anyone but i18n anyway. I would like to check it in for M6.

Checked in a fix today - 12:00pm 5/20/99.

** Checked with 5/22/99 Win32 build ** The bug was observable in both Composer and Mail Composer windows, The above fix seemed to have addressed the Composer problem but but not the Mail Composer one, I now understand what the conditions for Mail Composer are. Try the following steps to reproduce this problem. 1. Start Messenger: apprunner -mail 2. Start New Mail composer. 3. Now switch to Japanese input mode and put the cursor into the Mail body. Type in Japanese sequence and bring up the conversion window. Confirm that the entries are in Japanese. 4. Now, get out of the JPN IME mode (ALT + `) and click into the Address field. Type in your address, e.g. tague@foo.com. 5. Now get into the JPN IME mode (ALT + `). 6. Place the cursor into the body window, type in Japanese and bring up the conversion candiadtes window. This time all the candiadates display as blank squares. In stead of the steps 3-6 above, try a sequence in which: 3. Without the JPN IME on, type in address into the To: field., e.g. tague@foo,com 4. Now Place the cursor into the body window. Turn on JPN IME and type in some Japanese and bring up the conversion candidate window. You will see the blanks instead of Japanese. Basically, somehow the font is not selected correctly once you input into the header fields using non-IME mode.

I also should add that once the problem begins, it donesn't seem to go away simply because you finished one mail and begin another with a new Composer window. The font in the candidate window seems to get re-set for the duration of the current Messenger sesssion. One sure way to get back the Japanese font is to quit and re-start Messenger.

there's not much i can do for this right now, beyond the fix i've checked in. mailnews is using native text widgets not ender at the moment to support the headers. since we are eventually going to use ender for all text fields, i'm not going to spend alot of throw-away time to make this particular interaction work. i'll look at this again once ender is the text widget.

Clearing resolution field.

Much water has flowed since the last comment. This really needs to get re-tested with recent builds.

i wouldn't invest alot of time in retesting this until the dependency (enable ender as the text widget) has been fixed. it's a known problem that the native windows text widget is not being used correctly w.r.t. IME's.

moving to m11 while waiting on dependency.

Move to M11. The ender is turn on already. momoi, I change the QA contact to you since now this bug is in mail composition. Please retest it.

bulk reassign bugs to ftang for now

** Checked with 10/27/99 Win32 build (1999102708) ** The problem as I described it in my 5/23/99 notes (steps 1-6) no longer exists with the above build. Now the candidate window always uses the correct font. Marking it verified fixed.