Bug 144557

Summary:	(IIIMF canna) oocalc TAB fails to cancel preedit
Product:	[Fedora] Fedora	Reporter:	Warren Togami <wtogami>
Component:	openoffice.org	Assignee:	Caolan McNamara <caolanm>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	dcbw, eng-i18n-bugs, tagoh
Target Milestone:	---	Keywords:	i18n
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-04-05 20:11:34 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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):
openoffice.org-1.1.3-1.5.fc3
im-sdk-12.1-10.FC3

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
in IIIMF.

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 ***