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

[Yikai Zhao]

Hello Pip,

I have reproduced the issue with your patch, here's the relevant log:

(Lines starting with '#' are my comments)

dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0

# Pressed first character here. It goes to fcitx normally.

result 1 (not GTK) for event 2, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0
result 1 (not GTK) for event 3, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0
result 0 (not GTK) for event 3, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0

# Pressed second character here. It goes to fcitx normally.

result 1 (not GTK) for event 2, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0
result 1 (not GTK) for event 3, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0

# Pressed third character here. It goes to fcitx normally.

result 1 (not GTK) for event 2, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0

# BUG REPRODUCED HERE: Pressed fourth character here. It does not go
to fcitx. It goes to emacs instead.

result 0 (not GTK) for event 2, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0
result 1 (not GTK) for event 3, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0
result 0 (not GTK) for event 3, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0
result 1 (not GTK) for event 3, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0
result 0 (not GTK) for event 3, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0


Please let me know if there's any other info I can provide.

Thanks!


On Sun, Dec 1, 2024 at 12:37 AM Pip Cet <pipcet@protonmail.com> wrote:
>
> 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