Closed Bug 227970 Opened 21 years ago Closed 20 years ago

AIX: GTK2 Mozilla never resets the preedit string

Categories

(Core :: Internationalization, defect)

Other
AIX
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: pkwarren, Assigned: smontagu)

References

Details

(Keywords: intl)

Attachments

(1 obsolete file)

When using the Japanese input method on AIX (GTK2), the preedit string is never
reset after committing. So the first string is input and committed correctly,
but subsequent strings show the preedit string of all previous committed entries
plus the current one. Here is an example (with the '|' character representing
the caret, and brackets representing the preedit string):

[xyz]|         <- input 'xyz' into preedit string
[ab]|          <- preedit string is converted
ab|            <- preedit string is committed
ab[xyzab]|     <- input 'xyz' again. notice that the preedit 
                  string contains the previous committed entry.
ab[abab]|      <- preedit string is converted.
abab|          <- preedit string is committed
abab[xyzabab]| <- input 'xyz' again. preedit string now contains
                  both previous committed entries.
abab[ababab]|  <- preedit string is converted.
ababab|        <- preedit string is committed.

I have a temporary fix in my tree which calls gtk_im_context_reset() in
IM_commit_cb after the text has been committed. This resets the preedit string
after every commit, but I'm not sure if this is the correct method.
I'm not sure either, but if we could get some linux testing of the patch it
would help.  Can you upload the patch?
Blocks: gtk2
Attached patch Example Patch (obsolete) — Splinter Review
This does not do exactly what I want, since not only does it reset the preedit
string, but it also resets the XIM state. Usually, if you are in a certain
input mode (e.g. Hiragana), it will remain in that input mode until you change
to another mode. This patch causes the input mode to be reset to ascii input
mode every time the preedit string is committed.

I think what we really need is some way to reset the preedit string at the same
time the XNPreeditStartCallback is called. The old GTK1 code would reset the
preedit string in preedit_start_cbproc, but the old code kept a copy of the
preedit string so this was easily implemented. Since the preedit string is
internal to GTK2, I don't see a good way to accomplish this.

I am also seeing similar behavior when using the "Text Widget" example in
gtk-demo, so this might be a AIX/GTK2 bug more than a Mozilla bug.
Have you filed a bug upstream?  That might help.
Comment on attachment 137196 [details] [diff] [review]
Example Patch

This is not a good patch - this should be fixed in GTK instead of Mozilla.
Attachment #137196 - Attachment is obsolete: true
Filed http://bugzilla.gnome.org/show_bug.cgi?id=130617 to address the problem in
GTK2.
This has been fixed in GTK2 (starting with 2.4.0 release).
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: