The XIM code does not work properly. I'm going to mark a bunch of bugs as depending on this bug as they only happen with XIM on.

*** Bug 16645 has been marked as a duplicate of this bug. ***

*** Bug 15463 has been marked as a duplicate of this bug. ***

A mail bug was marked a duplicate of this - has to do with entering passwords where certain characters in the password is not accepted (doesn't show *). Adding myself to cc: list as this affects mail usage.

question: Did you turn XIM off as a workaround for now? Thanks.

yes

Tajima-san, please take a look at bugs 16645 and 15463. Pavlov says that these are related to this XIM problem.

Tajima-san, please also use email with pavlov@netscape.com to figure out what the problem(s) are with the XIM code. Please Cc me or mozilla-i18n@mozilla.org. Thanks!

pavlov, the description in this bug report is very vague, Please follow the bug reporting guideline in http://www.mozilla.org/quality/bug-writing-guidelines.html to write the bug report. Is the problem only in password field ?

tajima seems to have found the problem. see below: ------- Additional Comments From tajima@eng.sun.com 10/19/99 16:43 ------- In nsGtkEventHandler.cpp's XIM code, I made an assumption that keycode value of a keyevent remains 0(zero) when the keyevent came through XIM, but it seems that it is not always true. Actually, nsPlatformToDOMKeyCode() returns 0 for a '!', and due to this, my XIM code processes the event as XIM event, and commit '!'. To solve the problem, I'm seeking for correct way to know which is the event from XIM, and which is not. However, I also like to know whether the current nsPlatformToDOMKeyCode()'s behaviour is right or not with the '!' event.

I think akkana@netscape.com might be a good person to talk to for nsPlatformToDOMKeyCode issues. For GTK/GDK IM issues, talk to otaylor@redhat.com.

No, that doesn't sound right. Sounds like we need an entry for the exclam in nsKeycodes[], earlier in that file, mapping whatever gtk returns for ! to whatever the ns keycode is.

We may need to massively change nsPlatformToDOMKeyCode()/nsConvertCharCodeToUnicode(), which are called from InitKeyEvent()/InitKeyPressEvent(). nsConvertoCharCodeTOUnicode() do not do to-unicode conversion, so it only works with ASCII + Latin1 string value. nsPlatformToDOMKeyCode() does not even cover all ascii range, and none of non-ascii range, latin1, kana is covered.

If there is something wrong with nsPlatformToDOMKeyCode() and nsConvertCharCodeToUnicode(), that should be fixed by someone other than tajima, since tajima is working on XIM, not regular ASCII key stuff. Pavlov? Akkana?

Indeed, we would be able to fix the current problem with '!' or others by putting more entires in nsPlatformToDOMKeyCODE(), but we can still input non-'*' into the passwd field through XIM. Two solutions come across to me are: 1. The widget for the passwd field should listen to nsTextEvent as well as regular nsKeyEvent, so that the text in both the events should be replaced with "*". or: 2. We should have a way to disable XIM for some widgets like password field.

Tajima-san, you have a lot of experience with input methods, so correct me if I'm wrong, but I believe password fields are intended to hide whatever the user is typing so that other people in the vicinity cannot see their password. If the input method is enabled, it might put up an over-the-spot window or a floating window ("root window" style). So I think input methods should be disabled for password fields, not only for Unix, but all the other platforms too.

Erik, you're right, So, in passwd fields, we will need to disable input methods for all platforms, that is XIM for UNIX, and no other choice.

OK, but if we need to be able to disable input methods for all platforms, we probably need an XP (back-end) design/API for this. Adding ftang to Cc list. However, it seems like the password issue and the key code issue discussed above are 2 separate issues, and should probably be separate bug reports. No?

You could reopen the bugs that I marked as duplicates of this one which seperate those out pretty well.

Akkana, if you are the correct owner for the 2 password bugs that I just reopened, then could you please change the USE_XIM_NOT back to USE_XIM after you have fixed the problem with '!' in the virtual key stuff?

If Erik thinks it's a dup, I'm marking it as so, since "XIM code does not work correctly" makes no sense on my buglist (I'm not working on XIM). I'm willing to uncomment the XIM stuff in my tree and make sure it works, though. *** This bug has been marked as a duplicate of 15463 ***

Akkana, would you check in the fix for USE_XIM_NOT -> USE_XIM after fixing the '!' stuff please? Thanks!

checked for duplication with 16645

Verified as dup.

setting to an approximate milestone so it can be off of the no TFV list