Closed Bug 227970 Opened 21 years ago Closed 21 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: 21 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: