Keyboard input gets jumbled when typing fast #2486

nekohayo · 2023-03-07T15:25:28Z

Environment

Fedora 37, with GNOME 43... as well as Fedora 38, with GNOME 44
Affects both the X11 and Wayland session, but Xorg/X11 is much more susceptible to it and a triple-buffered Mutter Wayland session is less susceptible to it
IBus 1.5.27 and 1.5.28

Which application and version?:

Pretty much any GTK4 application with a GtkEntry or GtkSearchEntry. The problem is reproducible using the gtk4-demo-application.

Issue description:

Mostly what the title says... but please see https://gitlab.gnome.org/GNOME/gtk/-/issues/5347 for details, as it was partially investigated there with @jtojnar & @fujiwarat

Steps to reproduce:

Type fast in any GTK4 application's text entry widget, especially when the application is doing some live processing (ex: searching) as a result of your typing. You could use the gtk4-demo-application for testing this, but you may need to use faster typing speeds; see also the ticket linked above for some way to do this programmatically. Note that Nautilus will be much less affected than other apps, because I have implemented some performance mitigation in its GtkSearchEntry that makes the issue less likely to occur.

Additional info:

Can you reproduce your problem when you restart ibus-daemon?: Yes (the problem is permanent)

Do you see any errors when you run ibus-daemon with the verbose option? (Run ibus-daemon --xim --verbose & and look at the output when you encounter your problem.)
I'm not sure how to do that when the current session already has an ibus-daemon, without messing up my session?

Can you reproduce your problem with a new user account instead of the current your account?: I haven't been able to try/test that.

The text was updated successfully, but these errors were encountered:

nekohayo · 2023-03-07T22:39:32Z

I will also add: I would tend to think that this has something to do with "stalling in the mainloop" or how busy the rest of the system is / what resources are available to ibus, because:

The issue used to happen excruciatingly often to Nautilus 43.0 until I worked around this problem (and other performance-related problems) with this approach that decoupled the searching from the typing, so that typing would actually not trigger any CPU and I/O in most cases; after doing that, Nautilus 43.1 (and newer) mostly stopped being affected by this ibus bug (until you happen to be typing at varying speeds, on a slower computer, and then the CPU/IO load caused by search queries might trigger the bug again...).
It was possible to observe the issue in GNOME Builder 43 when typing fast in the global search (Ctrl+Enter) or the in-file search (Ctrl+F) and the behavior would be like this: https://youtu.be/Cfrl3s01GAM ...but GNOME Builder 44 completely rewrote its search engine so it does not exhibit/trigger this ibus issue anymore.
The issue happens only if you type very fast (programmatically?) in gtk4-demo-application
I think also affected (and maybe still affects?) the GTK4 FileChooser widget's SearchEntry

frohro · 2023-03-27T17:32:03Z

I'm happy to test possible solutions for this. I am experiencing this bug with my Lenovo Yoga 260 with i3 processor.

fujiwarat · 2023-03-28T01:24:24Z

I need to get time to evaluate this issue since it's a bit complicated.

nekohayo · 2023-03-28T15:05:53Z

If some onlookers are able to read C code (I can't) and would like to check the "Could it be that it is using a stack (LIFO) queue somewhere instead of a FIFO?" hypothesis, maybe these can be areas to have a look at:

(I'm just blind-guessing here... but it would be fun if it turned out to be simply something like that)

fujiwarat · 2023-04-20T00:03:42Z

I also thought GQueue of the key events but seems it does not help to fix this issue.

This is the stack of nested _process_key_event() in another _process_key_event():

#0  0x00007f3b86ba9d1c in _process_key_event
    (context=0x7f3b4c00c550, event=0x7f3b4c079300, ibusimcontext=0x6bb1010)
    at /root/rpmbuild/BUILD/ibus-1.5.27/client/gtk4/ibusimcontext.c:544
#1  0x00007f3b86baaf7e in ibus_im_context_filter_keypress
    (context=0x6bb1010, event=0x7f3b4c079300)
    at /root/rpmbuild/BUILD/ibus-1.5.27/client/gtk4/ibusimcontext.c:1197
#2  0x00007f3b8a736047 in gtk_event_controller_key_handle_event ()
    at /lib64/libgtk-4.so.1
#3  0x00007f3b8a8b9392 in gtk_widget_run_controllers () at /lib64/libgtk-4.so.1
#4  0x00007f3b8a8b9679 in gtk_widget_event () at /lib64/libgtk-4.so.1
#5  0x00007f3b8aa4bc1e in gtk_propagate_event_internal.isra ()
    at /lib64/libgtk-4.so.1
#6  0x00007f3b8a7ab1ed in gtk_main_do_event.part () at /lib64/libgtk-4.so.1
#7  0x00007f3b8a8c780c in surface_event () at /lib64/libgtk-4.so.1
#8  0x00007f3b8a989417 in _gdk_marshal_BOOLEAN__POINTER ()
    at /lib64/libgtk-4.so.1
#9  0x00007f3b8a9b8c23 in gdk_surface_event_marshaller ()
    at /lib64/libgtk-4.so.1
#10 0x00007f3b8a12bef5 in g_closure_invoke () at /lib64/libgobject-2.0.so.0
#11 0x00007f3b8a159d86 in signal_emit_unlocked_R.isra.0 ()
    at /lib64/libgobject-2.0.so.0
#12 0x00007f3b8a148e16 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#13 0x00007f3b8a149633 in g_signal_emit () at /lib64/libgobject-2.0.so.0
#14 0x00007f3b8aa4bcd3 in gdk_surface_handle_event.isra ()
    at /lib64/libgtk-4.so.1
#15 0x00007f3b8a9f72be in gdk_event_source_dispatch.lto_priv ()
    at /lib64/libgtk-4.so.1
#16 0x00007f3b8a014eba in g_main_dispatch (context=0x1a85580)
    at ../glib/gmain.c:3444
#17 0x00007f3b8a01614b in g_main_context_dispatch (context=0x1a85580)
    at ../glib/gmain.c:4162
#18 0x00007f3b8a016356 in g_main_context_iterate
    (context=0x1a85580, block=1, dispatch=1, self=0x1d9ab30)
    at ../glib/gmain.c:4238
#19 0x00007f3b8a0164ac in g_main_context_iteration
    (context=0x1a85580, may_block=1) at ../glib/gmain.c:4303
#20 0x00007f3b86ba9e97 in _process_key_event
    (context=0x7f3b4c00c550, event=0x7f3b4c079060, ibusimcontext=0x6bb1010)
    at /root/rpmbuild/BUILD/ibus-1.5.27/client/gtk4/ibusimcontext.c:544
#21 0x00007f3b86baaf7e in ibus_im_context_filter_keypress
    (context=0x6bb1010, event=0x7f3b4c079060)
    at /root/rpmbuild/BUILD/ibus-1.5.27/client/gtk4/ibusimcontext.c:1197
#22 0x00007f3b8a736047 in gtk_event_controller_key_handle_event ()
    at /lib64/libgtk-4.so.1
#23 0x00007f3b8a8b9392 in gtk_widget_run_controllers () at /lib64/libgtk-4.so.1
#24 0x00007f3b8a8b9679 in gtk_widget_event () at /lib64/libgtk-4.so.1
#25 0x00007f3b8aa4bc1e in gtk_propagate_event_internal.isra ()
    at /lib64/libgtk-4.so.1
#26 0x00007f3b8a7ab1ed in gtk_main_do_event.part () at /lib64/libgtk-4.so.1
#27 0x00007f3b8a8c780c in surface_event () at /lib64/libgtk-4.so.1
#28 0x00007f3b8a989417 in _gdk_marshal_BOOLEAN__POINTER ()
    at /lib64/libgtk-4.so.1
#29 0x00007f3b8a9b8c23 in gdk_surface_event_marshaller ()
  7 at /lib64/libgtk-4.so.1
#30 0x00007f3b8a12bfc0 in g_closure_invoke () at /lib64/libgobject-2.0.so.0
#31 0x00007f3b8a159d86 in signal_emit_unlocked_R.isra.0 ()
    at /lib64/libgobject-2.0.so.0
#32 0x00007f3b8a148e16 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#33 0x00007f3b8a149633 in g_signal_emit () at /lib64/libgobject-2.0.so.0
#34 0x00007f3b8aa4bcd3 in gdk_surface_handle_event.isra ()
    at /lib64/libgtk-4.so.1
#35 0x00007f3b8a9f72be in gdk_event_source_dispatch.lto_priv ()
    at /lib64/libgtk-4.so.1
#36 0x00007f3b8a014eba in g_main_dispatch (context=0x1a85580)
    at ../glib/gmain.c:3444
#37 0x00007f3b8a01614b in g_main_context_dispatch (context=0x1a85580)
    at ../glib/gmain.c:4162
#38 0x00007f3b8a016356 in g_main_context_iterate
    (context=0x1a85580, block=1, dispatch=1, self=0x1d9ab30)
    at ../glib/gmain.c:4238
#39 0x00007f3b8a0164ac in g_main_context_iteration
    (context=0x1a85580, may_block=1) at ../glib/gmain.c:4303
#40 0x0000000000402bda in main (argc=1, argv=0x7ffe30e64c18) at window.c:274

E.g. if a key press and release happens very quickly, g_main_context_iteration() in the "KeyPress" _process_key_event() can call another "KeyRelease" _process_key_event() instead of the callback of _process_key_event_reply_done().
And the "KeyRelease" _process_key_event() receives the "KeyPress" _process_key_event_reply_done().
The "KeyPress" _process_key_event() cannot receive any _process_key_event_reply_done() with g_main_context_dispatch() until the "KeyRelease" _process_key_event() terminates g_main_context_dispatch() and returns because of the stack order.
And the the key event reorder issue happens.

So even if FIFO is used, the reverse order cannot be changed until g_main_context_dispatch() can call gdk_event_source_dispatch() besides g_idle_dispatch() for GDBusProxy.

Replacing g_main_context_dispatch() with g_usleep() cannot call _process_key_event_reply_done().

The possible solutions are:
#1. Use g_main_context_push_thread_default() and g_main_context_pop_thread_default() and try to restrict g_main_context_dispatch().
#2. Consider synced g_dbus_proxy_call_sync() from ibus_input_context_process_key_event() can receive DDBusProxy signal "CommitText" during g_dbus_proxy_call_sync().

I'm trying #1 but don't know the usage and cannot succeed it.

Regarding to #2, currently it's impossible as the D-Bus specification:
https://mail.gnome.org/archives/gtk-devel-list/2017-August/msg00045.html

nekohayo · 2023-04-23T17:38:56Z

I don't know if this additional "easy way to trigger the issue" is helpful at this point, but in case it is:

I discovered today that one of the remaining affected applications is Epiphany. With version 44.1 on Intel graphics and Xorg (didn't test Wayland, but I think it would be less likely to exhibit the issue than on Xorg), if I go to GMail and try to write an email there by typing rapidly (more than 50-70 words per minute?), the email's text contents will be garbled; in fact, it's nearly impossible for me to type an email with it unless I force myself to type very slowly.

jtojnar · 2023-05-07T20:33:49Z

I discussed it with Company on #gnome-hackers on April 23. Apparently, nested main loops are not really supported by GTK.

But as mentioned in the GTK issue, using IBUS_ENABLE_SYNC_MODE=1 fixes it so why not use that by default with GTK 4?

fujiwarat · 2023-05-08T09:27:04Z

As I noted, IBUS_ENABLE_SYNC_MODE=1 has a problem with D-Bus specification:

Regarding to #2, currently it's impossible as the D-Bus specification:
https://mail.gnome.org/archives/gtk-devel-list/2017-August/msg00045.html

If an IBus engine calls ibus_enigne_commit_text() during waiting for the return of ibus_input_context_process_key_event(), the commit-text D-Bus signal cannot be reached before ibus_input_context_process_key_event() returns.
That's why IBus has been used the async APIs.

I discussed it with Company on #gnome-hackers on April 23. Apparently, nested main loops are not really supported by GTK.

So my possible idea is:

#1. Use g_main_context_push_thread_default() and g_main_context_pop_thread_default() and try to restrict g_main_context_dispatch().

I think If g_dbus_proxy_call() can call with a specific GMainContext and g_main_context_iteration() can wait for the callback of DBus methods only to avoid the nested main loops. My understanding is Mutter uses g_main_context_push_thread_default().

ryan-beisner · 2023-05-10T14:39:51Z

FYI Ubuntu 22.10 with GNOME 43 and ibus 1.5.27, jumbled characters: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1996652

While the user types a search query, we restart our search engines for every key stroke. This is desirable for quick results. But unlike other engines, starting the simple engine multiple times in rapid succession can put some stress on system resources. Depending on the hardware and windowing system, this may result in user perception of poor performance and even aggravate race condition bugs, such as ibus/ibus#2486. Previously, we've dealt with this by setting the delay directly in the search entry. But that was a bad solution because it draged down the responsiveness of other search engines. So, save resources by starting the simple engine IO thread one second later, as long as it's not stopped/restated in the meantime.

While the user types a search query, we restart our search engines for every key stroke. This is desirable for quick results. But unlike other engines, starting the simple engine multiple times in rapid succession can put some stress on system resources. Depending on the hardware and windowing system, this may result in user perception of poor performance and even aggravate race condition bugs, such as ibus/ibus#2486. Previously, we've dealt with this by setting the delay directly in the search entry. But that was a bad solution because it draged down the responsiveness of other search engines. So, save resources by starting the simple engine IO thread one second later, as long as it's not stopped/restated in the meantime. Bump glib minimum version to use "once" source helpers.

The synchronous "ProcessKeyEvent" D-Bus method cannot receive "CommitText" and "ForwardKeyEvent" D-Bus signals during calling the method. To resolve the issue, now ibus_input_context_set_post_process_key_event() and ibus_input_context_post_process_key_event() are added newly. ibus_input_context_post_process_key_event() retries "CommitText" and "ForwardKeyEvent" D-Bus signals during calling the "ProcessKeyEvent" D-Bus method and ibus-daemon does not handle those signals. BUG=ibus#2486

fujiwarat · 2023-06-30T04:18:08Z

I created a tentative patch. If you could test it, it would be great.

gunnarhj · 2023-06-30T18:55:38Z

I applied #2532 and uploaded ibus to an Ubuntu PPA to make testing easier for Ubuntu users.

gunnarhj · 2023-07-02T22:46:55Z

So far one Ubuntu user has reported improved performance due to the patch.

frohro · 2023-07-03T00:36:09Z

I applied the patch. I have two laptops that have been susceptible to this bug. I patched one of them. I then tried it, but it seemed it was still there. Then I rebooted that laptop and tried again, and have so far been unable to reproduce it in a certain fashion. I was typing as fast as I could to try and make the thing happen, and it did happen, but I think it was probably my fingers. :-) Even the unpatched laptop, however, seemed harder to make it happen, so I think other updates may have been masking the bug too. It still happens in a certain way on the unpatched laptop, but not as often as I remember it in the past. It was fairly painful in the past.

Okay, I'm sorry! I have one laptop with an i5 processor and the other with the i3. Unfortunately, the I3 processor, now that it is upgraded to the patch still shows the behavior. Sorry for the mistake above. I'm sure about these results. You don't even have to type that fast to see it.
Rob

fujiwarat · 2023-07-04T01:55:51Z

@frohro Did you apply the patch to ibus/client/gtk4 ? The GTK4 files are symlink of GTK2.

frohro · 2023-07-04T05:03:04Z

I went to the PPA that @gunnarhj made, added it, did sudo apt update, and sudo apt upgrade.

Rob

gunnarhj · 2023-07-04T06:20:22Z

And I forgot that (of course). Have now uploaded corrections to the PPA (wait for the builds to finish and the packages to be published before updating).

https://launchpad.net/~gunnarhj/+archive/ubuntu/ibus/+packages

Fix the synchronous "ProcessKeyEvent" D-Bus method in ibus-x11 too. Fixes: ibus@a73ea2c BUG=ibus#2486

fujiwarat · 2023-07-09T10:10:51Z

Revised the patches; #2532

gunnarhj · 2023-07-09T13:20:04Z

@fujiwarat: Thanks! The PPA has been updated with the latest versions of the two patches, and I can confirm that the x11 compose issue in gtk3 apps is no longer present.

nekohayo · 2023-07-10T17:18:17Z

I pushed the candidate patches to Fedora 39 for the testing before the upstream is fixed. I will update my IBus copr repository for Fedora 38 and 37 later including the patches and Plasma Wayland enhancements. [...]

@fujiwarat I presume you mean this COPR? As I'm on Fedora 38, I'll really be looking forward to that so I can easily test on all my machines :)

fujiwarat · 2023-07-11T06:44:05Z

@fujiwarat I presume you mean this COPR? As I'm on Fedora 38, I'll really be looking forward to that so I can easily test on all my machines :)

I delay to update the copr repo since I try to migrate the similar fix to ibus-wayland and refactor the codes for Plasma Wayland.
Let me finish to update Fedrao 38 copr today.

The synchronous "ProcessKeyEvent" D-Bus method cannot receive "CommitText" and "ForwardKeyEvent" D-Bus signals during calling the method. To resolve the issue, now ibus_input_context_set_post_process_key_event() and ibus_input_context_post_process_key_event() are added newly. ibus_input_context_post_process_key_event() retries "CommitText" and "ForwardKeyEvent" D-Bus signals during calling the "ProcessKeyEvent" D-Bus method and ibus-daemon does not handle those signals. "Since: 1.5.00" is added in header files to available APIs before 1.5.29 is released. Will think later how to convert the version comments together when the new version 1.5.29 is committed. BUG=ibus#2486

Fix the synchronous "ProcessKeyEvent" D-Bus method in ibus-x11 too. Fixes: ibus@3670faf BUG=ibus#2486

Fix the synchronous "ProcessKeyEvent" D-Bus method in ibus-wayland too. Also fix to send the correct keycode to ibus-hangul. Fixes: ibus@3670faf BUG=ibus#2486

fujiwarat · 2023-07-12T01:58:08Z

https://copr.fedorainfracloud.org/coprs/fujiwara/ibus/ provides ibus-1.5.28-13.1 for this issue.

fujiwarat · 2023-07-18T06:28:13Z

@nekohayo Did you have a chance to test my copr repository above?

nekohayo · 2023-07-19T02:11:26Z

Sorry for the delay and thank you for your patience (and package!) @fujiwarat ; I was away from home for a few days, and it took me longer than I anticipated to get back to my computer. I wanted to test this specific computer because it is the most affected and reproduces the bug easily.

I can confirm that the package from your COPR solves the issue compared to the mainline Fedora package. Awesome!

So this version exhibits the bug:

Name         : ibus
Version      : 1.5.28
Release      : 6.fc38
Architecture : x86_64
Size         : 111 M
Source       : ibus-1.5.28-6.fc38.src.rpm
Repository   : @System
From repo    : updates

...but this one doesn't:

Name         : ibus
Version      : 1.5.28
Release      : 13.1.fc38
Architecture : x86_64
Size         : 12 M
Source       : ibus-1.5.28-13.1.fc38.src.rpm
Repository   : copr:copr.fedorainfracloud.org:fujiwara:ibus

My methodology to test this now was to use the Xorg/X11 GNOME 44 session (because this will happen much more easily there than under Wayland), launch the Epiphany web browser (version 44.5 from the Fedora repositories), Ctrl+O to open a GtkFileChooser, select the "Home" folder, and try to rapidly type a long precise search query, such as "journal de bord". With the standard Fedora version, that string gets all jumbled up; with your COPR version, it gets written out as "journal de bord", with the letters in the correct order, no matter how much I/O or blocking there is going on.

Just to be sure, I then downgraded the package back to the standard Fedora version and the issue reappeared; re-upgraded to your COPR, and the issue vanished again.

Thank you very much!

fujiwarat · 2023-07-20T03:23:13Z

Thank you all for your tests.
I will integrate the patches next week.

Fix the synchronous "ProcessKeyEvent" D-Bus method in ibus-wayland too. Also fix to send the correct keycode to ibus-hangul. Fixes: ibus@3670faf BUG=ibus#2486

The synchronous "ProcessKeyEvent" D-Bus method cannot receive "CommitText" and "ForwardKeyEvent" D-Bus signals during calling the method. To resolve the issue, now ibus_input_context_set_post_process_key_event() and ibus_input_context_post_process_key_event() are added newly. ibus_input_context_post_process_key_event() retries "CommitText" and "ForwardKeyEvent" D-Bus signals during calling the "ProcessKeyEvent" D-Bus method and ibus-daemon does not handle those signals. "Since: 1.5.00" is added in header files to available APIs before 1.5.29 is released. Will think later how to convert the version comments together when the new version 1.5.29 is committed. BUG=#2486

Fix the synchronous "ProcessKeyEvent" D-Bus method in ibus-x11 too. Fixes: 38f09c6 BUG=#2486

Fix the synchronous "ProcessKeyEvent" D-Bus method in ibus-wayland too. Also fix to send the correct keycode to ibus-hangul. Fixes: ibus@3670faf BUG=ibus#2486

Fix the synchronous "ProcessKeyEvent" D-Bus method in ibus-wayland too. Also fix to send the correct keycode to ibus-hangul. Fixes: ibus@38f09c6 BUG=ibus#2486

Fix the synchronous "ProcessKeyEvent" D-Bus method in ibus-wayland too. Also fix to send the correct keycode to ibus-hangul. Fixes: 38f09c6 BUG=#2486

BillyCroan · 2023-11-12T19:02:54Z

I was experiencing this in Debian Bookworm, and asked them to backport this patch. They did, but I still experience the bug on 1.5.29 in x11.

gir1.2-ibus-1.0/stable-backports,now 1.5.29~~rc1-1~~bpo12+1 amd64 [installed,automatic]
ibus-data/stable-backports,stable-backports,now 1.5.29~~rc1-1~~bpo12+1 all [installed,automatic]
ibus-gtk3/stable,now 1.5.27-5 amd64 [installed,automatic]
ibus-gtk4/stable,now 1.5.27-5 amd64 [installed,automatic]
ibus-gtk/stable,now 1.5.27-5 amd64 [installed,automatic]
ibus-hangul/stable,now 1.5.4-2 amd64 [installed,automatic]
ibus-m17n/stable,now 1.4.19-1 amd64 [installed,automatic]
ibus-mozc/stable,now 2.28.4715.102+dfsg-2.2 amd64 [installed,automatic]
ibus/stable-backports,now 1.5.29~~rc1-1~~bpo12+1 amd64 [installed]
libibus-1.0-5/stable-backports,now 1.5.29~~rc1-1~~bpo12+1 amd64 [installed,automatic]
libusb-1.0-0/stable,now 2:1.0.26-1 amd64 [installed,automatic]
libusb-1.0-0/stable,now 2:1.0.26-1 i386 [installed,automatic]
libusbmuxd6/stable,now 2.0.2-3 amd64 [installed,automatic]
libusbredirhost1/stable,now 0.13.0-2 amd64 [installed,automatic]
libusbredirparser1/stable,now 0.13.0-2 amd64 [installed,automatic]
python3-ibus-1.0/stable-backports,stable-backports,now 1.5.29~~rc1-1~~bpo12+1 all [installed,automatic]

Was this patch intended to completely fix the out of order letters, or make it less common? I do think it's about 30% improved from before, but it still happens quite a lot. Mainly I see it in nautilus, when I'm trying to search for a file by name in my (large) homedir.

I start typing in a fresh nautilus window, and of course after the first letter probably half of the contents would match. so that search immediately runs up the cpu and memory, and as I add letters it narrows the search. It might be smart to not begin those searches unless there's at least 3 or 4 letters or the user hits enter.

Slowness aside though, out of order input is an ibus problem isn't it?

gunnarhj · 2023-11-12T19:32:59Z

@BillyCroan: I see that some binary packages (ibus-gtk, ibus-gtk3, ibus-gtk4) are still version 1.5.27. Please upgrade also those packages from the backports repo and let us know if it makes a difference.

BillyCroan · 2023-12-10T10:58:54Z

Yes. that seems to have fixed it. Thank you guys!!! Only my own typos futz up the input now. I can type full speed and there might be a delay before the letters appear, or the search actuates in nautilus. But when it does it's exactly what I typed. Works Great! Thank you @gunnarhj !

fujiwarat mentioned this issue Apr 19, 2023

When type very quickly in font dialog the input character order is reversed #2465

Closed

fujiwarat mentioned this issue Jun 30, 2023

src: Fix sync ibus_input_context_process_key_event() #2532

Closed

fujiwarat added Type-Enhancement OpSys-All Component-Persistence Priority-High ibus Component-Logic gtk4 xorg labels Jun 30, 2023

fujiwarat added a commit to fujiwarat/ibus that referenced this issue Jul 9, 2023

client/x11: Fix sync ibus_input_context_process_key_event()

dd7e858

Fix the synchronous "ProcessKeyEvent" D-Bus method in ibus-x11 too. Fixes: ibus@a73ea2c BUG=ibus#2486

fujiwarat added a commit to fujiwarat/ibus that referenced this issue Jul 11, 2023

client/x11: Fix sync ibus_input_context_process_key_event()

e495f80

Fix the synchronous "ProcessKeyEvent" D-Bus method in ibus-x11 too. Fixes: ibus@3670faf BUG=ibus#2486

fujiwarat mentioned this issue Jul 13, 2023

Update sync mode to use GMainLoop #2535

Open

fujiwarat added a commit that referenced this issue Jul 25, 2023

client/x11: Fix sync ibus_input_context_process_key_event()

7502abb

Fix the synchronous "ProcessKeyEvent" D-Bus method in ibus-x11 too. Fixes: 38f09c6 BUG=#2486

fujiwarat added this to the 1.5.29 milestone Jul 25, 2023

fujiwarat closed this as completed Jul 25, 2023

fujiwarat added a commit that referenced this issue Jul 27, 2023

client/wayland: Fix sync ibus_input_context_process_key_event()

7b83a1f

Fix the synchronous "ProcessKeyEvent" D-Bus method in ibus-wayland too. Also fix to send the correct keycode to ibus-hangul. Fixes: 38f09c6 BUG=#2486

Staudey mentioned this issue Sep 27, 2023

Nautilus search: keyboard input gets read in wrong order under load (ibus issue) getsolus/packages#402

Open

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Keyboard input gets jumbled when typing fast #2486

Keyboard input gets jumbled when typing fast #2486

nekohayo commented Mar 7, 2023 •

edited

nekohayo commented Mar 7, 2023

frohro commented Mar 27, 2023

fujiwarat commented Mar 28, 2023

nekohayo commented Mar 28, 2023

fujiwarat commented Apr 20, 2023

nekohayo commented Apr 23, 2023

jtojnar commented May 7, 2023 •

edited

fujiwarat commented May 8, 2023

ryan-beisner commented May 10, 2023

fujiwarat commented Jun 30, 2023

gunnarhj commented Jun 30, 2023

gunnarhj commented Jul 2, 2023

frohro commented Jul 3, 2023 •

edited

fujiwarat commented Jul 4, 2023

frohro commented Jul 4, 2023

gunnarhj commented Jul 4, 2023

fujiwarat commented Jul 9, 2023

gunnarhj commented Jul 9, 2023

nekohayo commented Jul 10, 2023

fujiwarat commented Jul 11, 2023

fujiwarat commented Jul 12, 2023

fujiwarat commented Jul 18, 2023

nekohayo commented Jul 19, 2023 •

edited

fujiwarat commented Jul 20, 2023

BillyCroan commented Nov 12, 2023

gunnarhj commented Nov 12, 2023

BillyCroan commented Dec 10, 2023

Keyboard input gets jumbled when typing fast #2486

Keyboard input gets jumbled when typing fast #2486

Comments

nekohayo commented Mar 7, 2023 • edited

nekohayo commented Mar 7, 2023

frohro commented Mar 27, 2023

fujiwarat commented Mar 28, 2023

nekohayo commented Mar 28, 2023

fujiwarat commented Apr 20, 2023

nekohayo commented Apr 23, 2023

jtojnar commented May 7, 2023 • edited

fujiwarat commented May 8, 2023

ryan-beisner commented May 10, 2023

fujiwarat commented Jun 30, 2023

gunnarhj commented Jun 30, 2023

gunnarhj commented Jul 2, 2023

frohro commented Jul 3, 2023 • edited

fujiwarat commented Jul 4, 2023

frohro commented Jul 4, 2023

gunnarhj commented Jul 4, 2023

fujiwarat commented Jul 9, 2023

gunnarhj commented Jul 9, 2023

nekohayo commented Jul 10, 2023

fujiwarat commented Jul 11, 2023

fujiwarat commented Jul 12, 2023

fujiwarat commented Jul 18, 2023

nekohayo commented Jul 19, 2023 • edited

fujiwarat commented Jul 20, 2023

BillyCroan commented Nov 12, 2023

gunnarhj commented Nov 12, 2023

BillyCroan commented Dec 10, 2023

nekohayo commented Mar 7, 2023 •

edited

jtojnar commented May 7, 2023 •

edited

frohro commented Jul 3, 2023 •

edited

nekohayo commented Jul 19, 2023 •

edited