Closed Bug 16670 Opened 25 years ago Closed 25 years ago

XIM code does not work correctly

Categories

(Core :: Internationalization, defect, P1)

x86
Linux
defect

Tracking

()

VERIFIED DUPLICATE of bug 15463

People

(Reporter: pavlov, Assigned: akkzilla)

Details

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
Assignee: erik → tajima
Severity: normal → critical
Priority: P3 → P1
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.
Assignee: tajima → akkana
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?
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
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!
Blocks: 17432
checked for duplication with 16645
Status: RESOLVED → VERIFIED
Verified as dup.
setting to an approximate milestone so it can be off of the no TFV list
Target Milestone: --- → M11
No longer blocks: 17432
You need to log in before you can comment on or make changes to this bug.