Bug 161250

Summary: Strange cell behavior on window focus, data entry, etc.
Product: [Fedora] Fedora Reporter: Aaron Gaudio <madcap>
Component: iiimfAssignee: Akira TAGOH <tagoh>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 4CC: eng-i18n-bugs, hdegoede, hensonneilneil
Target Milestone: ---Keywords: i18n
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-09-29 05:30:16 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 Aaron Gaudio 2005-06-21 18:54:04 UTC
Description of problem:
Under certain (common) circumstances, gnumeric acts as if I have started typing
in a cell when I haven't, which forces me to enter Escape to cancel it, or else
it ends up overwriting cell data.

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

How reproducible:
Always

Steps to Reproduce:
Window Focus problem-

1. Enter some data into some cells in gnumeric sheet
2. Leave the cell selection on a cell with data in it
3. Change window focus to another window in your window manager (I'm using
sawfish with [sloppy] mouse focus)
4. Change window focus back to gnumeric

Data Entry problem-

1. Enter some data into a cell
2. Select the cell directly above the cell you entered data into in step 1.
3. Enter data into the selected cell and press 'Enter'
  
Actual results:
In the window focus case, the gnumeric begins editing the currently selected
cell as soon as window focus returns to gnumeric.
In the data entry case, gnumeric begins editing the cell immediately below the
cell you just entered data into.

Expected results:
In the window focus case, nothing should happen when focus is returned to the
gnumeric window.
In the data entry case, the cell immediately below the edited cell should be
selected, but editing should *not* begin.

Additional info:

Comment 1 Hans de Goede 2005-06-21 20:13:52 UTC
I cannot reproduce either of the two problems using the current rawhide tree and
metacity with click to focus as windowmanager.

This could mean that the problem is fixed in newer gtk/gnome-libs in rawhide or
that it is sawfish specific (more likely).

Unfortunatly I don't have an FC4 install to test plain FC4.

Please:
-try this under rawhide and/or
-file a bug against sawfish and/or
-file a bug upstream*

*Even if this is a gnumeric bug as a packager I'm not going to be able to fix it


Comment 2 Aaron Gaudio 2005-06-22 03:47:02 UTC
Okay I've experimented a little more. First, let me say I mispoke... I don't use
sawfish anymore I'm running metacity (latest from FC4). Sorry for that confusion.

I tried running a vnc server with twm and could not reproduce the problem. Then
I ran a vnc server with metacity and could not reproduce it. After that, I tried
gdmflexiserver to get another real X server, logged into a Failsafe session and
tested with both twm and metacity- could not reproduce. Yet it continued to
happen on my main session. 

After all this, I think it is an iiim issue. I had iiim running on my main
server and none of the others. After shutting down the iiim service, removing
the gnome-im-switcher-applet (which has started locking up anyway, and doesn't
provide the chinese language that it ought to) and re-logging in, lo and behold
gnumeric no longer has this behavior.

So... perhaps this should be re-opened and assigned to the iiim category...

Comment 3 Hans de Goede 2005-06-22 04:55:31 UTC
Ok, reopening and asigning to iiim.

Comment 4 Hans de Goede 2005-06-22 04:56:55 UTC
Tago, Reassigning to you (after changing the component to iiim) read above why.


Comment 5 Akira TAGOH 2005-06-22 06:13:04 UTC
Does it happen when you press ctrl+space to deactivate the input method after
you finished to enter the data into the cell? I'm not sure what exactly are you
doing during editing at the cells. I don't see any relation why this is IIIMF
issue ATM. please let us know further information with the exact steps you did.

Comment 6 Aaron Gaudio 2005-06-22 12:28:16 UTC
I didn't do anything other than have the iiim daemon and
gnome-im-switcher-applet   (gimlet) running. I did not hit cntrl-space, in fact
I am currently unable to add a language other than ASCII to gimlet (even though
I have the le-chinput module installed). Nevertheless, when I ran gnumeric with
GTK_IM_MODULE unset (I have it normally set to 'iiim'), gnumeric ran as normal.

Gnumeric also runs normally now when I do not have gimlet running (but I can
still have iimd running and GTK_IM_MODULE set to 'iiim'). Whether this is a
gnumeric bug or an iiim bug, I dunno.

Comment 7 Akira TAGOH 2005-06-22 21:57:56 UTC
Ok, which locale are you using then?

Comment 8 Aaron Gaudio 2005-06-22 22:21:31 UTC
My locale is the default (no $LANG set), which I assume is either C, or en_US. 

Comment 9 Akira TAGOH 2005-06-22 22:58:15 UTC
You mean you logged into the desktop from gdm with the English language (en_US)
right? if you aren't sure which locale are you using, please try 'locale' on the
terminal program like gnome-terminal.

Comment 10 Aaron Gaudio 2005-06-23 02:58:40 UTC
I logged into gdm without selecting a language. Typing locale produces this:

LANG=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

I can try forcing this to en_US and see what happens...

Comment 11 Aaron Gaudio 2005-06-23 03:25:28 UTC
Okay... logging in after manually selecting 'en_US' seems to keep gimlet from
freezing up, and Chinese is once again listed as an available language (and in
fact can be used).

However, the gnumeric problem persists. I am setting GTK_IM_MODULE=iiim in my
~/. bashrc, so everything in my desktop has it by default. If I run gnumeric
using 'GTK_IM_MODULE= gnumeric', I don't get the problem. The problem exists no
matter what language I have selected via gimlet (Latin, 中æ, or ASCII). I've
also tried logging in as another user without GTK_IM_MODULE set, in the en_US
locale, with gimlet running, and I get similar behavior in gnumeric when I
manually set GTK_IM_MODULE=iiim.

Of note- when using iiim, gnumeric doesn't let me use the chinese input when
editing a cell (by clicking the cell and editing it), but if I go to the input
window and type, I can enter in Chinese there. Maybe this just boils down to
poor input method handling in gnumeric? If you concur, I'll refile this upstream. 

But I think the issue with the 'POSIX' locale messing up gimlet is a real
problem. Maybe it's a holdover from my FC4 upgrade? Is there a way to set the
'System Default' locale in gdm to be en_US?


Comment 12 Akira TAGOH 2005-06-23 04:09:01 UTC
Ok, confirmed. though there is a workaround for this issue on gnumeric as other
applications works, the real problem is in IIIMF. I'll investigate this then.

Comment 13 Akira TAGOH 2006-09-29 05:30:16 UTC
I'm sorry, we do not have enough time to do fix this issue. please contact
upstream directly if you really need to get this fix. thanks.

Comment 14 Aaron Gaudio 2006-09-29 06:05:45 UTC
This seems to be fixed in the latest FC5 release of gnumeric anyways. Thanks.

Comment 15 Josh 2022-02-02 17:56:32 UTC Comment hidden (spam)