Bug 144557 - (IIIMF canna) oocalc TAB fails to cancel preedit
(IIIMF canna) oocalc TAB fails to cancel preedit
Status: CLOSED DUPLICATE of bug 137398
Product: Fedora
Classification: Fedora
Component: openoffice.org (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Caolan McNamara
: i18n
Depends On:
  Show dependency treegraph
Reported: 2005-01-08 05:58 EST by Warren Togami
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:
Last Closed: 2005-04-05 16:11:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Warren Togami 2005-01-08 05:58:22 EST
Description of problem:
In oocalc hitting the TAB key causes current cell to jump to the right. 
Unfortunately if you are using IIIMF canna input in a cell, and hit TAB during
preedit before committing text, it goes to the right cell without canceling
preedit.  Subsequent IIIMF state is not proper.  SPACE brings up the candidate
selection window.  Other keys do nothing.  ENTER a few times cancels preedit
with apparently no effect, but it does recover from this state.

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

Steps to Reproduce:
1. Run oocalc.
2. Enable Japanese IIIMF input.
3. Type 'nihongo' then TAB
4. (BUG A) Type anything, nothing happens
5. Hit ENTER a few times to recover.
6. Type 'nihongo' then TAB
7. (BUG B) Hit SPACE SPACE, select anything, no effect.

Actual results:
Cell changes with TAB, but preedit is not canceled, leading to unexpected behavior.

Expected results:
Commit then preedit should be canceled immediately upon jumping cell.
Comment 1 Akira TAGOH 2005-02-23 04:59:04 EST
It seems oocalc doesn't call gtk_im_context_reset() when TAB was pressed. I
could reproduce this problem with/without gtk_im_context_reset() implementation
Comment 2 Dan Williams 2005-03-07 01:04:44 EST
Fixed in:

RHEL3: 1.1.2-22.2.2.EL3
RHEL4: 1.1.2-22.6.EL4

Still needs to be forward-ported to FC2 & FC3.
Comment 3 Warren Togami 2005-03-18 19:03:09 EST
Would forward porting be difficult?  We had several FC updates of OOo lately...
Is this fixed in 2.0 beta upstream too?
Comment 4 Caolan McNamara 2005-03-21 03:59:14 EST
caolanm->dcbw: is this done already for fc2/fc3 ?
Comment 5 Warren Togami 2005-03-21 04:59:56 EST
openoffice.org-1.1.3-9.5.0.fc3 is not yet fixed.
Comment 6 Dan Williams 2005-03-22 00:45:09 EST
Fixes are only in RHEL3 and RHEL4 builds at this time.  I've got a patch for 2.0 that I'll be forwarding to 
caolan, and I'll patch up the FC3 builds soon.  However, are we able/willing to push updated IIIMF to 
FC2 to support this, or is that not possible?
Comment 7 Warren Togami 2005-03-22 03:35:20 EST
Updating IIIMF in FC2 will require updating xinitrc too, which is usually a
risky endeavor.  I am looking at feasibility now as well as making FC2 and FC3
update candidates of im-sdk.
Comment 8 Warren Togami 2005-03-22 05:02:17 EST
mharris is making me follow some procedure that involves product management and
business justification in order to make this change happen in FC2 xinitrc.  I
don't have time for this especially given that FC2 will be transferred to Legacy
soon, so im-sdk will not be upgraded on FC2.

IIRC openoffice.org was never functional at all with FC2 IIIMF, so upgrading
openoffice without im-sdk really isn't much of a loss.  Thoughts?

FC3 openoffice.org and im-sdk will be an easy upgrade.
Comment 9 Warren Togami 2005-03-29 02:59:02 EST
ping dcbw, can we go ahead with the openoffice.org updates?
Comment 10 Dan Williams 2005-04-05 16:11:34 EDT
duping this to Bug 137398 as that has the fixes for this.

Warren:  can you test and verify the packages in 137398 comment #17?

*** This bug has been marked as a duplicate of 137398 ***

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