Bug 144557 - (IIIMF canna) oocalc TAB fails to cancel preedit
Summary: (IIIMF canna) oocalc TAB fails to cancel preedit
Status: CLOSED DUPLICATE of bug 137398
Alias: None
Product: Fedora
Classification: Fedora
Component: openoffice.org (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
Target Milestone: ---
Assignee: Caolan McNamara
QA Contact:
Keywords: i18n
Depends On:
TreeView+ depends on / blocked
Reported: 2005-01-08 10:58 UTC by Warren Togami
Modified: 2007-11-30 22:10 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-05 20:11:34 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Warren Togami 2005-01-08 10:58:22 UTC
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 09:59:04 UTC
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 06:04:44 UTC
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-19 00:03:09 UTC
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 08:59:14 UTC
caolanm->dcbw: is this done already for fc2/fc3 ?

Comment 5 Warren Togami 2005-03-21 09:59:56 UTC
openoffice.org-1.1.3-9.5.0.fc3 is not yet fixed.

Comment 6 Dan Williams 2005-03-22 05:45:09 UTC
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 08:35:20 UTC
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 10:02:17 UTC
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 07:59:02 UTC
ping dcbw, can we go ahead with the openoffice.org updates?

Comment 10 Dan Williams 2005-04-05 20:11:34 UTC
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.