bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Pip Cet <pipcet@protonmail.com> writes:
>
>> On Saturday, November 30th, 2024 at 10:55, Gerd Möllmann 
>> <gerd.moellmann@gmail.com> wrote:
>>> Helmut Eller eller.helmut@gmail.com writes:
>>> 
>>> > On Fri, Nov 29 2024, Gerd Möllmann wrote:
>>> > 
>>> > > > Not sure if that is used in your build, but in x_display_info 
>>> > > > (xterm.h)
>>> > > > I see a number of struct frame pointers that are not fixed in 
>>> > > > fix_frame,
>>> > > > starting with
>>> > > > 
>>> > > > struct frame *x_focus_frame;
>>> > > > 
>>> > > > And if it's not that display info that is being used, I'd bet a small
>>> > > > amount that whatever is actually used (pgtk_display_info?) has a 
>>> > > > similar
>>> > > > problems.
>>> > > > 
>>> > > > (Can't fix this myself, sorry, I only have macOS.)
>>> > 
>>> > I think the x_display_info struct (I guess usually only one exists) is
>>> > allocated in x_term_init (or pgtk_term_init) with igc_xzalloc_ambig. So
>>> > theoretically it doesn't need to be traced.
>>> 
>>> 
>>> Then we're good, sorry for the noise.
>>
>> So it turns out X input method handling is somewhat complicated!
>>
>> I've tried installing fcitx, but it seems to be working the same here with 
>> and without MPS.
>>
>> It would help to establish the value of x-gtk-use-native-input, since that 
>> determines whether we use the GTK or X method for communicating with fcitx.
>>
>> I've attached a patch which logs some debugging info to stderr
>> (because displaying messages using X while debugging X code is a bad
>> idea, IME). If you could apply it and reproduce the output around a
>> keypress that's handled incorrectly, that might help us track this
>> down.
>>
>> Pip
>
> Searching for "closure" and "user_data" turns up this in gtkutil.c:
>
>   static void
>   xg_im_context_commit (GtkIMContext *imc, gchar *str,
>                         gpointer user_data)
>   {
>     struct frame *f = get_glib_user_data (user_data);
>
> That's a Gtk signal handler, or whatever they are called, which
> gets set, also in gtkutil.c
>
>   g_signal_connect_data (G_OBJECT (imc), "commit",
>                        G_CALLBACK (xg_im_context_commit),
>                        glib_user_data (f), free_glib_user_data,
>                        G_CONNECT_DEFAULT);
>
> Looks to me like a struct frame * might be "hidden" by this in some Gtk
> data structure so that it can be passed to the handler at some point.
>
> Don't know if that's relevant.

It probably isn't relevant because of this

  #ifdef HAVE_MPS
  void free_glib_user_data (gpointer data, GClosure *closure)
  {
    igc_xfree (data);
  }
  #else
  void free_glib_user_data (gpointer data, GClosure *closure)
  {
    return;
  }
  #endif

Don't know where the allocation takes place.

I should shut up, I guess :-).