Red Hat Bugzilla – Bug 130751
IM commiting in the wrong direction in gtkhtml
Last modified: 2014-03-25 20:50:47 EDT
Description of problem:
This situation only occurs in Evolution Mail when creating a new Mail
Message. In other widgets the LE works fine.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. In the ko locale, open Evolution
2. Select the Mail compoent and create a new Mail Message
3. In the main Mail Messgae area, start using hangul LE
Characters get committed from right to left.
Characters should be committed from left to right.
Shouldn't this be assigned to evo/gtkhtml3 or something then?
Looking into the problem it is definitely about gtkhtml. Moving the
Debugged as follow:
- Currently when you enter string into preedit buffer, gtkhtml will
create preedit area (a text with black background attr) at the cursor
- The problem arises when a input method commits a string while
preedit buffer is not empty, the string will be committed at the
cursor position again
- Hence the string is behind of "preedit area" as the preedit area did
- When the input method commits another string, it will be at the back
of the first committed string
Created attachment 103672 [details]
proposed patch - first draft
Attached is the proposed patch. I have tested in CJK input methods and
they worked okay with it.
I haven't tested it, but the patch looks sane to me. Owen's working
on the 3.3.0 branch so I'd like his opinion before I apply (and
hopefully we can get it upstream)
The patch makes sense to me, if you want to file it upstream,
Leon, I'll say the same there.
Dave & Owen, thanks! Filed and attached my proposed patch &
Owen, I found out a problem on the current implementation is it
affects normal non-IM typing coz it uses commit as well. This is a
better patch for ignoring the positioning when typing in english so
that it gets positioning correctly on all occasions now. If you can
commit again asap then it would be wonderful. Apologies on this.
Test case tested:
1. moving cursor then type
2. return then type
3. insert between characters
a. normal english typing
b. korean (partial commit)
c. traditional chinese (full commit)
d. indic hindi
Created attachment 103937 [details]
new patch for above description
Tested with Leon's gtkhtml3 test build which includes the patch,
korean input has been resolved.
In additional, tested with en, ja, tw and cn to ensure the patch does
not affect other input. The result is very positive.
I'm seeing some problems with the latest gtkhtml3 in rawhide (bug
#113104); are they related to these changes?
Sorry, that should have read bug #133104
3.3.2 is completely screwed up, yes, you probably want to dup that
bug on this. I have a candidate patch that I'm going to build into
the build system now. Not sure it is better for CJK, but at least
should make the composer usable for English.
(This has been my top priority bug for the last day, since I'd
like to be able to compose mail...)
*** Bug 133104 has been marked as a duplicate of this bug. ***
gtkhtml3-3.3.2-3 (in Rawhide) has what I think is a pretty good
set of fixes for this problem. It tests out for me with various
*** Bug 133173 has been marked as a duplicate of this bug. ***
*** Bug 133202 has been marked as a duplicate of this bug. ***
Rawhide works for me too, shouldn't we close this bug?
I have tested rawhide with CJK and en_US input with the scenario
described in this bug together with bug 133104, bug 133173 and bug
If possible, we will resolve the bug after receving confirmation from
I have tested hindi with gtkhtml3-3.3.2-3 (from Rawhide) for this
issue using UnitLE. Confirmed that the characters are input correctly
from left to right.
Thanks Jatin. Confirmed fixed in rawhide and resolving this bug.