After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 663371 - Switching away from current Gnumeric window with Alt-Tab causes current cell text to get deleted
Switching away from current Gnumeric window with Alt-Tab causes current cell ...
Status: RESOLVED NOTABUG
Product: Gnumeric
Classification: Applications
Component: GUI
1.10.x
Other Linux
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2011-11-04 04:23 UTC by Luke Hutchison
Modified: 2012-04-21 00:41 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Luke Hutchison 2011-11-04 04:23:56 UTC
When viewing a Gnumeric spreadsheet with the cursor over a cell that contains some nonempty value, if I hit Alt-Tab to switch to some other window, then when I switch back, the contents of the current cell has been set to empty, and the cell has entered edit mode (as if F2 then Ctrl-A then Backspace had been pressed).  

This is an incredibly dangerous bug because using Alt-Tab can result in data loss that can go unnoticed -- nobody would ever expect Alt-Tab to wipe the current cell, and you never see it happening because it happens while the other window is moved in front of Gnumeric, so you're even less likely to notice the change when you switch back.

Observed in current stable versions of Gnumeric on Fedora for at least the last year (sorry, I thought I already reported this but can't find a bug report about it). Just tested on gnumeric-1.10.17 on Fedora 15, bug still present.
Comment 1 Jean Bréfort 2011-11-04 07:16:18 UTC
I'm unable to reproduce either with current trunk or with 1.10.17 on Debian sid.
Comment 2 Andreas J. Guelzow 2011-11-04 15:06:33 UTC
Gnumeric does not handle alt-tab switching to a different window. That is done by the window manager.

To delete a cell content of a selected cell, you do not need "F2 then Ctrl-A then Backspace", Just Backspace or Delete will delete the content.

I assume that just switching windows without the alt-tab does not cause the deletion, so it is not GNuemric acting on an out-of-focus event.

It is clear that something must be passed to Gnumeric causing that deletion. Apparently your window manager leaks part of the keystroke to Gnumeric.

I would consider that a window manager bug. Please file this bug against your window manager.

I am marking this as NOT_GNOME but really mean here NOT-GNUMERIC, since you might be using a GNOME window manager.
Comment 3 Luke Hutchison 2011-11-04 16:19:51 UTC
(In reply to comment #2)

> To delete a cell content of a selected cell, you do not need "F2 then Ctrl-A
> then Backspace", Just Backspace or Delete will delete the content.

Right, but not only is the content of the cell gone after switching back, but also the cell is in edit mode.

> I assume that just switching windows without the alt-tab does not cause the
> deletion, so it is not GNuemric acting on an out-of-focus event.

Correct, clicking on window buttons doesn't cause the problem, just doing Alt-Tab.

> It is clear that something must be passed to Gnumeric causing that deletion.
> Apparently your window manager leaks part of the keystroke to Gnumeric.

Maybe -- although nothing about Alt nor Tab key events could cause this effect, so some other event must be getting through.

> Gnumeric does not handle alt-tab switching to a different window. That is done
> by the window manager.
> [...]
> I would consider that a window manager bug. Please file this bug against your
> window manager.

Right, but this problem manifests on multiple different Fedora 15 machines (actually probably from Fedora 12 to 15) using both Metacity and the XFCE4 window manager.  I don't think therefore that this is a window manager bug, unless XFCE4's window manager inherits some buggy code from Metacity.

Is there some way of turning on debug so it's possible to see which events are being received by Gnumeric?
Comment 4 Andreas J. Guelzow 2011-11-05 00:35:27 UTC
There is no debugging code that you could switch on for this purpose. If you use a debugger such as gdb, The function that handles the keystrokes in question is gnm_pane_key_mode_sheet
Comment 5 Andreas J. Guelzow 2011-11-05 01:56:03 UTC
Trying Gnumeric with xfce on ubuntu 11.04 works fine. I don't see what you observe.
Comment 6 Luke Hutchison 2012-02-18 01:51:24 UTC
I'm still seeing this in Fedora 16 under XFCE and GNOME -- switching away from a window causes the current cell to enter edit mode, and the contents are wiped.

I really would like to get this bug fixed, as it is very easy to trigger (just focus another window) and has very serious ramifications (you lose the value in the current cell, possibly without noticing). I think I tracked down what is at least triggering the problem (IBus). Can you please re-open this bug?

I tried setting a breakpoint at gnm_pane_key_mode_sheet as Andreas suggested, and it doesn't seem to exist, but I set one at gnm_pane_key_press. I realized it would stop at the breakpoint even when I just hit Alt (to perform Alt+Tab), so it was not a good way to test triggering the bug with Alt+Tab. Instead, I tried simply clicking away from the window onto another visible Window, and the same problem occurred even without keyboard input.

I tried setting a breakpoint at gnm_pane_edit_start, clicked to focus another window, and got the following backtrace:

  • #0 gnm_pane_edit_start
    at gnm-pane.c line 2289
  • #1 scg_edit_start
    at sheet-control-gui.c line 3112
  • #2 wbcg_edit_start
    at wbc-gtk-edit.c line 1091
  • #3 cb_gnm_pane_preedit_changed
    at gnm-pane.c line 775
  • #4 g_closure_invoke
    at gclosure.c line 774

From what I can tell, this is an input method callback. I have IBus running, with input methods for English (Dvorak), Korean and Chinese (Pinyin). I suspect that the input method is somehow interfering with Gnumeric. Which of the two is misbehaving?

What do I look at next? I'm happy to run any tests to debug this.
Comment 7 Luke Hutchison 2012-02-18 02:30:32 UTC
I confirm that it looks like shutting down IBus fixes the problem. Still not sure if it's IBus sending a bad input method code or Gnumeric handling input method instructions badly though.
Comment 8 Andreas J. Guelzow 2012-02-18 07:22:44 UTC
Gnumeric should not see any input method instructions. THey should be handled before Gnumeric sees any of the input.
Comment 9 Andreas J. Guelzow 2012-02-18 16:48:24 UTC
I am reopening this but I think the "NOTGNUMERIC" assessment still applies.
Comment 10 Luke Hutchison 2012-02-18 23:49:17 UTC
Looks like this is a problem with all the major input method frameworks (not just IBus, but also uim and SCIM) -- it was reported and fixed already in OpenOffice's gsl library by canceling the preedit operation for any preedit-changed signals corresponding to zero-length preedit strings:

https://issues.apache.org/ooo/show_bug.cgi?id=49311

In fact there are vestiges of having hit something like this before in cb_gnm_pane_preedit_changed() -- see the comment below. Should the logic here be changed slightly so that it is more robust to event noise coming from the input method?


static void
cb_gnm_pane_preedit_changed (GtkIMContext *context, GnmPane *pane)
{
	gchar *preedit_string;
	int tmp_pos;
	int cursor_pos;
	WBCGtk *wbcg = pane->simple.scg->wbcg;
	GtkEditable *editable = gnm_pane_get_editable (pane);

	tmp_pos = gtk_editable_get_position (editable);
	if (pane->preedit_attrs)
		pango_attr_list_unref (pane->preedit_attrs);
	gtk_im_context_get_preedit_string (pane->im_context, &preedit_string, &pane->preedit_attrs, &cursor_pos);

	/* in gtk-2.8 something changed.  gtk_im_context_reset started
	 * triggering a pre-edit-changed.  We'd end up start and finishing an
	 * empty edit every time the cursor moved */
	if (!pane->reseting_im &&
	    !wbcg_is_editing (wbcg) && !wbcg_edit_start (wbcg, TRUE, TRUE)) {
		gtk_im_context_reset (pane->im_context);
		pane->preedit_length = 0;
		if (pane->preedit_attrs)
			pango_attr_list_unref (pane->preedit_attrs);
		pane->preedit_attrs = NULL;
		g_free (preedit_string);
		return;
	}

	if (pane->preedit_length)
		gtk_editable_delete_text (editable,tmp_pos,tmp_pos+pane->preedit_length);
	pane->preedit_length = strlen (preedit_string);

	if (pane->preedit_length)
		gtk_editable_insert_text (editable, preedit_string, pane->preedit_length, &tmp_pos);
	g_free (preedit_string);
}
Comment 11 Luke Hutchison 2012-02-19 00:07:08 UTC
Sorry for the continuing comments, but after thinking about this a little harder, sending a zero-length preedit string upon change of focus is probably intentional behavior on the part of the input method, and would be intended to reset the preedit prefix so that preedits don't migrate along with the window focus. Throwing away vestigal preedit text upon window switch is expected behavior for composed languages.

For most programs, sending an empty preedit string won't cause anything user-visible to happen. In Gnumeric's case, it puts the cell into edit mode with an empty string in the edit buffer rather than the current cell contents. (In fact I don't think there's even a way to generate the observed behavior in any user-intended way, with just the keyboard/mouse and without switching window focus, because F2 will enter edit mode but with the current cell contents in the edit buffer, Delete will delete the contents but not enter Edit mode, and there's no way to actually type or preedit-type an empty string.)

At the very least, the default behavior in Gnumeric should probably be, "if the user edits a cell, and doesn't actually type anything over the top, then edit the existing text in the cell". However, if the preedit string is empty, not entering edit mode at all is a better fix, since the former expected behavior can't even be triggered under normal usage with the keyboard/mouse.
Comment 12 Luke Hutchison 2012-04-16 19:37:36 UTC
This problem appears to have gotten worse: in recent Fedora updates, every time I open a Gnumeric document (on two different computers, in XFCE with the keyboard switcher set up to switch between QWERTY and Dvorak), Gnumeric immediately starts in cell edit mode with empty edit text in the cell the user was viewing last time the spreadsheet was opened.

This means if the cursor was over some critical piece of text when the spreadsheet was saved, and the user later re-opens the spreadsheet, that critical cell value is not even displayed, only the empty edit string. If the user hits *anything* other than Escape -- including Enter, or even arrow keys, or even if the user just clicks with the mouse somewhere else to get out of edit mode, the original value in that cell is *erased*, with no indication given to the user since the moment the spreadsheet was opened that there was even ever anything in that cell.

*Please* can this be fixed. Even if it's the IME's fault, Gnumeric needs to detect this case and deal with it appropriately, or data loss can result. It's easy to detect, because an empty preedit string in pre-edit-changed is meaningless.
Comment 13 Andreas J. Guelzow 2012-04-16 22:24:00 UTC
The fix should be in the software that causes this problem. I am also using a current Fedora (but Gnome, not XFCE) and do not experience any such problem.

If a keycode is passed to Gnumeric, Gnumeric has to assume that it was in fact typed by a user. There is no reasonable way in which GNumeric can discover that there is a problem with some other software so that the keystroke should be ignored.
Comment 14 Luke Hutchison 2012-04-21 00:41:33 UTC
Thanks for your patience, and sorry it took me a while to follow your reasoning about the problem being upstream. Fixed in iBus.

https://bugzilla.redhat.com/show_bug.cgi?id=813125