GNOME Bugzilla – Bug 319407
Wrong Backspace behavior using GTK+ HEAD
Last modified: 2006-04-10 07:22:37 UTC
I switched my test GNOME installation under /opt/gnome from GTK+ stable (2.8) to HEAD. Now when I press the backspace key to delete the character to the right side of the cursor (ltr environment), the character is not deleted. Instead the cursor goes before the character to delete, as well as I pressed left_arrow key. Example | is the cursor, trying to write "this is the wrong behavior" a. on screen "this is the wrom|" b. <press backspace to delete 'm'> c. on screen "this is the wro|m " d. <press backspace another time> e. on screen "this is the wr|m" Note that additional space at c. step was added by GTKHTML and removed in e. d1. <press righ-arrow> e1. on screen "this is the wrom| " f. <press backspace another time> g. on screen "this is the wro| " Additional info - Only the first Backspace press seems to fail - Backspace works fine trying to delete a space (i.e. "wrong " -> bksp --> "wrong " - Pasting some text, then hitting backspace seems works fine, as well as moving the cursor here and there on page then bakcspacing. Troubles only typing before backspace. - The issue is present in both stable and HEAD branch of GTKHTML, when used upon GTK+ head. Could it be related to glib updated to Unicode 4.1? glib ChangeLog says this update could break some application. - Any other "simple" GTK+ text widgets (gedit, terminal, text entries) work fine - Ctrl+Backspace shortcut to delete the entire word has a similar behavior: move the cursor at begin of the word, don't delete the word but add a space at the end.
*** Bug 321884 has been marked as a duplicate of this bug. ***
this can result in data loss because the undo function does not work correctly. raising priority and severity.
...and just to clarify: i also have been seeing this constantly here for weeks.
FWIW, I suddenly started seeing this in Evo on Win32, too, today. Never noticed it before.
Can't reproduce this here, but I'm using gtk-2-8 and evolution from CVS HEAD.
It appears to have something to do with the specific input method in use. In html_engine_delete, we have the following: html_engine_block_selection (e); html_engine_set_mark (e); html_engine_update_selection_if_necessary (e); html_engine_freeze (e); (cursor motion) html_engine_delete (e); html_engine_unblock_selection (e); html_engine_thaw (e); The trouble occurs in html_engine_freeze when it goes to reset the input method, it eventually winds up in gtk_html_im_preedit_changed_cb which carefully saves and restores the selection while doing work, but doesn't save the mark. As a result, the mark is lost at this point, so when html_engine_delete is called, there is no mark, so no selection is created and nothing ends up getting deleted. Is the fix as simple as moving the call to html_engine_freeze before the call to set the mark? That works for me, as you'll see in the proposed patch.
Created attachment 60529 [details] [review] freeze html engine before setting mark in html_engine_delete
applied the patch, also works for me. gaaareat! anyone willing to review?
well, i should add that i', running evo2.5.92cvs on suse9.3/gnome2.10 here. this definitely should be tested on a system where this bug did not occur before to make sure that there are no side effects.
Hmm, so the Ctrl-Shift hex unicode input stuff has changed in HEAD, I didn't know that. That presumably then is the root cause. Could it be that there is some slight bug in GTK+ HEAD gtkimcontextsimple.c so that IM-related signals (preedit_changed?) are emitted even if no IM stuff is going on? Is the problem that gtk_im_context_simple_commit_char() calls g_signal_emit_by_name (context_simple, "preedit_changed") unconditionally? In 2.8 it doesn't.
It looks like maybe the code in simple_commit_char should be if (context_simple->tentative_match || context_simple->in_hex_sequence) { context_simple->tentative_match = 0; context_simple->tentative_match_len = 0; g_signal_emit_by_name (context_simple, "preedit_changed"); } Does that help, Tor ?
Unfortunately not. I wonder if the change for #301015 is related?
Adding the same condition to gtk_im_context_simple_reset() helps. Matthias says on IRC it really is gtkhtml's bug if it can't handle superfluous preedit_changed signals, but nothing wrong in avoiding extra emissions either. Workaround added in gtk+ HEAD: 2006-03-03 Tor Lillqvist <tml@novell.com> * gtk/gtkimcontextsimple.c (gtk_im_context_simple_commit_char) (gtk_im_context_simple_reset): Avoid emitting superfluous preedit_changed signals. Thanks to Matthias. (#319407)
I see this bug is still marked 'NEW' here; Tor -- is this fixed?
Yes, fixed. Resolving.