Lost input in quickfill cells due to race

[Christian Stimming]

Dear Jim,

in May you sent us a very useful patch to get rid of lost characters during 
auto-completion ("quickfill") of text input in the account register window.

However, subsequently I noticed a change in behaviour of the register auto-
completion. Namely, during typing sometimes the cursor jumps to the end of the 
selection where instead it previously stayed inside the selection, or more 
precisely, when typing a quick-filled word character by character, the cursor 
previously stayed right after the character that was just typed, but now it 
occasionally jumps to the end of the selection. In effect, when typing 
"Groceries", I type "G r o", but after the "G r" the cursor jumped to the end 
of the selection and I end up with the word "Grocerieso", which is annoying.

Reverting your patch from May (r20689) will make this behaviour go away again. 
This is Ubuntu 10.10 with gtk-2.20.1. I don't want to revert your patch right 
away as I'm sure you had some other bugs that went away by your patch, but 
this particular other issue was introduced by it. (Unfortunately, it also went 
into the stable 2.4.6 already, so it needs to be fixed there as well...)

Do you have any ideas here?

Regards,

Christian


Am Dienstag, 24. Mai 2011 schrieb Jim Paris:
> I've been looking at it some more and came up with the below fix,
> which seems to work.  The keyboard input ends up in the commit_cb
> which calls gtk_editable_insert_text then gtk_editable_set_position.
> It's the call to _set_position that clears the selection!
> 
> I think this might be a bug in GTK+, because gtk_entry_real_set_position
> does this:
> 
>   if (position != priv->current_pos ||
>       position != priv->selection_bound)
>     {
>       _gtk_entry_reset_im_context (entry);
>       gtk_entry_set_positions (entry, position, position);
>     }
> 
> The test is basically always true.  I don't think that || was
> intended: priv->current_pos is the start of the selection,
> priv->selection_bound is the end of it.  If the test were &&, then
> an attempt to position the cursor at either end of the selection
> wouldn't have cleared it.