This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 134505 - Ooo commits preedit strings before the actual commit
Ooo commits preedit strings before the actual commit
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: openoffice.org (Show other bugs)
rawhide
All Linux
medium Severity high
: ---
: ---
Assigned To: Dan Williams
: i18n
Depends On:
Blocks: FC3Target
  Show dependency treegraph
 
Reported: 2004-10-04 01:17 EDT by Leon Ho
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-21 11:13:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Leon Ho 2004-10-04 01:17:42 EDT
Description of problem:
Starting from 1.1.2-7 (1.1.2-{5,6} were fine) the preedit string get
committed even tho the conversation isn't finished. Hence many extra
characters get committed into document.

Version-Release number of selected component (if applicable):
1.1.2-7

How reproducible:
everytime

Steps to Reproduce:
1. LANG=ja_JP.UTF-8 oowriter
(1a. compare to LANG=ja_JP.UTF-8 gedit)
2. ctrl-space
3. type "sushi" + "space"


Actual results:
the preedit string is committed before it convert to kanji

Expected results:
up the that stage (3), only kanji is convert in preedit area. not
suppose to have anything committed.

Additional info:
Comment 1 Leon Ho 2004-10-05 11:34:09 EDT
Major i18n problem for -7 as it cannot allow japanese and korean IM to
input correctly. This problem will make japanese and korean users
unusable on OOo. I would like to put this to higher severity. This
will block fc2 updates being pushed using -7.

I checked some new codes from /patches/vclplug/xim-fixes.diff are
pushed to gtkframe.cxx so i assume the problem lies around there.
Comment 2 Dan Williams 2004-10-05 11:38:59 EDT
Michael Meeks has made some "improvements" in the IM code recently,
perhaps that fixes it...  I'll do a 1.1.2-8 soon so you can test that
and see if that fixes it.
Comment 3 Dan Williams 2004-10-05 11:48:53 EDT
Hmm, I'm wrong, 1.1.2-7 includes those "improvlements".  Anyway, can
you help me reproduce?

1) Which iiimf-* packages do i need to install?
2) Do I simply need to start htt_server, or what do I need to do to
start that?
3) Then I set my LANG and launch OOo?
Comment 4 Leon Ho 2004-10-05 12:56:38 EDT
No problem. Hopefully the info on IIIMF and the src in IRC helps. Let
me know if you need anything else.
Comment 5 Dan Williams 2004-10-05 16:37:19 EDT
Ok.  Problem is that OOo attempts to squash key release events by
keeping around the last key press event, and matching against the next
key release event.  If they match, nothing is done.  If they key
release event is for a different key, OOo will end the preedit mode
and leave the current preedit text in the buffer.  This was triggered
by the xim-fixes.diff patch.  Key press/release events are not always
being received in paired order for some reason, hence the problem.

Its unclear why OOo needs to do this, and its also quite broken since
you're not guaranteed to receive key press/release events in
sequential order.

A partial fix will be in 1.1.2-8, but you must exit preedit mode to
use menu accellerators (ie, Alt+F or Alt+O while preediting won't work).

Leon, it seems that the IIIMF gimlet is accepting GDK key events with
accellerators, like Alt+F, and it probably shouldn't.  Why is that? 
You'll notice in the new version if you type Alt+F, the F gets stuck
into the preedit stream, indicating that the gimlet "handled" the event.
Comment 6 Dan Williams 2004-10-05 16:42:16 EDT
1.1.2-8 should be built by the time you wake up tomorrow, Leon.
Comment 7 Leon Ho 2004-10-06 01:59:45 EDT
Thanks for the fix - It partially fixed the problem.

Here is a situation of preedit still being committed before actual commit:
1. ctrl-space
2. type "sushi"
3. press "end"
(preedit is commit; and preedit buffer is hidden)
4. type "nippon"
(preedit buffer (sushi) is shown again along with nippon)

Other than "end" key, you can also reproduce with "shift"+"." etc..

--
For accelerators, LE (language engine, i.e. cannaLE) have power to
receive it when LE is activiated, but LE do not generally use the
common accelerators.

However for cannaLE, i tested with:
1. ctrl-space
2. type "wa"
3. Alt-F

the menu seems highlighted but it is not expanded, so openoffice.org
seems can able receive the I have tested with gedit and seems LE does
not catch Alt-F.
Comment 8 Akira TAGOH 2004-10-06 13:48:41 EDT
erm, on gtk2 apps, gtk2 grabs the key event before dispatching it to
the libraries and/or the applications. so what you saw on gedit is,
because of LE doesn't catch Alt-F. correctly because of gtk2 grabbed
Alt-F first.
Comment 9 Akira TAGOH 2004-10-06 13:50:16 EDT
grr, s/because of LE/not that because of LE/
Comment 10 Dan Williams 2004-10-06 23:28:50 EDT
Leon, please test with 1.1.2-9 in rawhide now
Comment 11 Leon Ho 2004-10-07 09:06:43 EDT
Sorry Dan, unfortunately I still can reproduce it in -9:
1. ctrl-space
2. type "sushi"
3. press shift
(preedit should commit but it is committed; and preedit buffer is
hidden; in gedit, press shift does not do anything)
4. type "nippon"
(preedit buffer (sushi) is shown again along with nippon)

I have also tried your modified lib in people.r.c, and I couldn't able
to activiate the LE after restart OOo. 

Let me know what else can I able to assist on this problem.
Comment 12 Leon Ho 2004-10-07 09:11:31 EDT
s/(preedit should commit/(preedit should not be committed/
Comment 13 Akira TAGOH 2004-10-07 09:15:22 EDT
I've also tested 1.1.2-9. unfortunately it's still broken - just to
cralify, yesterday's shared library didn't support gtk2 yet, right?
llch just noticed that it didn't work without httx (XIM-IIIMF bridge
program) when he overwrote it onto -9.
the below testcase still fails on -9 anyway, using XIM or IIIM.

1. make sure htt_server and cannaserver is running
2. run oowriter with LANG=ja_JP.UTF-8 XMODIFIERS=@im=none
GTK_IM_MODULE=iiim
or
2.a. run httx with LANG=ja_JP.UTF-8
2.b. run oowriter with LANG=ja_JP.UTF-8 XMODIFIERS=@im=htt
GTK_IM_MODULE=xim

3. press ctrl+space s u s h i shift

result:
preedit line is hidden. but it didn't happens on -8 + the libs with httx.
Comment 14 Warren Togami 2004-10-18 09:04:11 EDT
This test case may be easier to understand and see visibly bad effects.

Description of problem:
While using cannaLE in openoffice writer, there is strange behavior
with the "!" key where the uncommitted characters before the "!" are
duplicated.

Version-Release number of selected component (if applicable):
12.0.1-17.svn1994
openoffice.org-1.1.2-9

Steps to Reproduce:
1. Activate cannaLE in openoffice.org writer.
2. Type "sugoi" but do not commit.
3. Type "!" and let go of the spacebar.
4. Type "!" and let go of the spacebar.
5. Type "!" and let go of the spacebar.

Actual Results:
Each time you hit "!" after uncommitted text, it duplicates all of
that text along with a "!" appended to the end.  You can only avoid
the duplication of text if you use ENTER to commit prior to hitting "!".
Comment 15 Dan Williams 2004-10-18 15:02:36 EDT
Ok, root cause is iiimf (gtkimcontextiiim.c in im-sdk) which creates
"fake" key events in iiim_event_dispatch().

Gdk receives the keypress, calls OOo.  OOo calls iiim, which creates
the "fake" key press events and posts them to the GDK event queue. 
OOo then receives those key events later and ends preedit.

The questions are:
1) Why does IIIMF create these key events
2) Why does GTK not have issues with the events, but OOo does
3) How do we fix OOo to act the way GDK/GTK does, OR
4) How do we fix IIIMF to not act this way
Comment 16 Dan Williams 2004-10-21 11:13:37 EDT
Mostly fixed in 1.1.2-10, some other problems are iiimf-related
(gtk_im_context_reset ()).

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