Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 130751 - IM commiting in the wrong direction in gtkhtml
IM commiting in the wrong direction in gtkhtml
Product: Fedora
Classification: Fedora
Component: gtkhtml3 (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Malcolm
: i18n
: 133104 133173 133202 (view as bug list)
Depends On:
Blocks: IIIMF 131589
  Show dependency treegraph
Reported: 2004-08-24 06:11 EDT by Lawrence Lim
Modified: 2014-03-25 20:50 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-23 02:31:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
proposed patch - first draft (914 bytes, patch)
2004-09-10 02:52 EDT, Leon Ho
no flags Details | Diff
new patch for above description (1.13 KB, patch)
2004-09-16 21:08 EDT, Leon Ho
no flags Details | Diff

  None (edit)
Description Lawrence Lim 2004-08-24 06:11:35 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):
im-sdk 11.4-70.svn1875

How reproducible:

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
Actual results:
Characters get committed from right to left.

Expected results:
Characters should be committed from left to right.

Additional info:
Comment 1 Jens Petersen 2004-08-31 00:05:05 EDT
Shouldn't this be assigned to evo/gtkhtml3 or something then?
Comment 2 Leon Ho 2004-09-09 03:10:33 EDT
Looking into the problem it is definitely about gtkhtml. Moving the
Comment 3 Leon Ho 2004-09-10 02:51:30 EDT
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
not move.
- When the input method commits another string, it will be at the back
of the first committed string
Comment 4 Leon Ho 2004-09-10 02:52:27 EDT
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.
Comment 5 Dave Malcolm 2004-09-10 12:00:43 EDT
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)
Comment 6 Owen Taylor 2004-09-10 12:13:21 EDT
The patch makes sense to me, if you want to file it upstream,
Leon, I'll say the same there.
Comment 7 Leon Ho 2004-09-10 14:21:59 EDT
Dave & Owen, thanks! Filed and attached my proposed patch & 
description: http://bugzilla.ximian.com/show_bug.cgi?id=65670
Comment 8 Leon Ho 2004-09-16 21:07:57 EDT
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
Comment 9 Leon Ho 2004-09-16 21:08:57 EDT
Created attachment 103937 [details]
new patch for above description
Comment 10 Lawrence Lim 2004-09-17 05:14:09 EDT
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.

Comment 11 Dave Malcolm 2004-09-21 14:24:57 EDT
I'm seeing some problems with the latest gtkhtml3 in rawhide (bug
#113104); are they related to these changes?
Comment 12 Dave Malcolm 2004-09-21 14:26:30 EDT
Sorry, that should have read bug #133104
Comment 13 Owen Taylor 2004-09-21 14:31:22 EDT
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...)
Comment 14 Owen Taylor 2004-09-21 19:06:28 EDT
*** Bug 133104 has been marked as a duplicate of this bug. ***
Comment 15 Owen Taylor 2004-09-22 09:19:50 EDT
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
input methods.
Comment 16 Owen Taylor 2004-09-22 09:21:07 EDT
*** Bug 133173 has been marked as a duplicate of this bug. ***
Comment 17 Dave Malcolm 2004-09-22 10:48:21 EDT
*** Bug 133202 has been marked as a duplicate of this bug. ***
Comment 18 Colin Walters 2004-09-22 17:02:13 EDT
Rawhide works for me too, shouldn't we close this bug?
Comment 19 Lawrence Lim 2004-09-22 18:45:26 EDT
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
Indic input.
Comment 20 Jatin Nansi 2004-09-23 02:05:49 EDT
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.
Comment 21 Lawrence Lim 2004-09-23 02:31:50 EDT
Thanks Jatin. Confirmed fixed in rawhide and resolving this bug.

Note You need to log in before you can comment on or make changes to this bug.