Bug 134022 - oocalc cannot input with input method after first cell input
Summary: oocalc cannot input with input method after first cell input
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: openoffice.org
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dan Williams
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 137149
TreeView+ depends on / blocked
 
Reported: 2004-09-29 01:05 UTC by Leon Ho
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version: openoffice.org-i18n-1.1.2-18.6.EL4
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-12-16 06:44:24 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Leon Ho 2004-09-29 01:05:14 UTC
Description of problem:
When you enter string through input method into first cell, it works.
however, second onwards cannot able to input.

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

How reproducible:
everytime

Steps to Reproduce:
1. LANG=ja_JP.UTF-8 oocalc
2. ctrl-space to activiate input method
3. type "sushi" enter at the first cell
4. type "sushi" enter at the second cell
  
Actual results:
first cell shows sushi characters, second cell doesn't

Expected results:
any cell will accept input

Additional info:

Comment 1 Dan Williams 2004-10-19 18:47:01 UTC
Accepted.  The reason that preedit ends is that the user is using the
mouse or the arrow keys to move between cells.  That ends preedit mode
for OOo.

The IM code in OOo has no way of knowing when you're in the
Spreadsheet and to allow the user to move around when in the
spreadsheet but not in the Writer module.

Note that Gnumeric (a real GTK app) exhibits the same behavior with
IIIMF, it ends preedit when you move between cells and you have to hit
Ctl+Space twice to reenable preedit.

So where is the bug?  Is it in IIIMF, GTK, or OOo?  What should the
real behavior be?

Comment 2 Leon Ho 2004-10-20 04:24:27 UTC
Well i think ends on moving to different cells make sense.

But this bug is that after the string is committed by user on one
cell, *and then* move to another cell, retype preedit and commit will
not show anything

Actually the test lib you sent me resolve the vertical movement:
1. ctrl-space
2. type "sushi" and then enter in A1
3. press down arrow to move to A2
4. type "sushi" enter

This works.

However this:
1. ctrl-space
2. type "sushi" and then enter in A1
3. press right arrow to move to B1
4. type "sushi" enter

*Does* not work.

Probably related to the other input bug that we have?

Comment 3 Dan Williams 2004-11-15 14:32:58 UTC
Nov 22 is the probable target date for starting work on this.

Comment 4 Leon Ho 2004-11-30 03:59:28 UTC
Comment #2 still can reproduce on 1.1.2-14.6.EL4.

Comment 5 Akira TAGOH 2004-12-01 04:32:22 UTC
For additional testcase,
1. ctrl-space
2. type "sushi" and then enter in A1
3. press Right key to move to B1
4. type "sushi" enter
5. type "sushi" enter

The second time "sushi" is put into the cell B1.

Comment 6 Akira TAGOH 2004-12-01 07:22:05 UTC
FYI, moving the text cursor with Tab key and the mouse works. this
problem happens with only the arrow keys.

Comment 7 Dan Williams 2004-12-08 03:25:03 UTC
Was fixed in 1.1.2-16.6.EL

Comment 8 Lawrence Lim 2004-12-16 06:44:24 UTC
Confirmed fixed in openoffice.org-i18n-1.1.2-18.6.EL4. Check in all
CJK locale following the Test Cases earlier.


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