Description of problem: Inputting hangul marchs in place in gnome-terminal Version-Release number of selected component (if applicable): 1.5.1-2.fc29.x86_64 How reproducible: always Steps to Reproduce: 1. launch gnome-terminal 2. input hangul (switch hangul, click any keys) 3. Actual results: click rrrrrr (with ibus-hangul) Expected results: click rrrrrr (with ibus-hangul) ㄲㄲㄲㄲ Additional info: ibus-1.5.19-4.fc29.x86_64 gnome-shell-3.30.0-8.fc29.x86_64 xorg-x11-server-Xwayland-1.20.1-2.fc29.x86_64 libwayland-server-1.16.0-1.fc29.x86_64
Could you describe more about how to reproduce this issue?
I think this and bug #1632646 is same. Seems if preedit is updated before the text is committed, gtk serial numbers are different and text_input_commit_apply() is failed.
(In reply to fujiwara from comment #2) > I think this and bug #1632646 is same. > Seems if preedit is updated before the text is committed, gtk serial numbers > are different and text_input_commit_apply() is failed. Yes. When inputting with ibus-hangul, the same problem happens in libreoffice.
(Note this is unrelated to bug 1628462)
Proposing this as a F29 Final Blocker since it affects input of Japanese and Korean in important applications like gnome-terminal and libreoffice.
Discussed during the 2018-10-08 blocker review meeting: [1] The decision to classify this bug as an AcceptedFreezeException and to punt (postpone decision) on blocker status was made: "Punt (delay decision) on blocker, AcceptedFreezeException (Final) - this is definitely bad enough to warrant a freeze exception. We were not certain on blocker status; we would like to know if any other input methods, particularly major Chinese ones, are affected in order to be able to make a decision" [1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2018-10-08/f29-blocker-review.2018-10-08-16.00.log.txt
There is now a proposed fix for this, but it seems like it was a bit too simple and may need further work: https://gitlab.gnome.org/GNOME/gtk/merge_requests/384
Discussed during the 2018-10-15 blocker review meeting: [1] The decision to classify this bug as an "AcceptedBlocker" was made as a conditional violation of the "basic functionality test" criterion when affected input methods are used, certainly including Japanese and Korean and likely also affecting some Chinese IMs. [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2018-10-15/f29-blocker-review.2018-10-15-16.00.txt
libreoffice calls two gtk_im_context_set_cursor_location() for one updating preedit and I will file a libreoffice bug separated from this bug after a mutter fix is landed and I'd suggest only this bug of gnome-terminal can be a blocker.
Just a quick note for the status: there are several fixes being discussed for this, both in gtk+ and mutter. Carlos Garnacho is working on it and will try to land one of the fixes for this week's GNOME 3.30.2 release. In addition to the gtk+ and mutter fixes, it's likely there's a separate libreoffice issue (https://bugzilla.redhat.com/show_bug.cgi?id=1632981#c9) that may need fixing separately.
Scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=30397704 Pull request: https://src.fedoraproject.org/rpms/mutter/pull-request/13
Thanks Jonas, this looks good to me so far in my inital testing. I am able to input both Japanese (kkc) and Korean (hangul) in a F29 Gnome Wayland session running your mutter scratch build.
mutter-3.30.1-4.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-081ab1aeb9
mutter-3.30.1-4.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-081ab1aeb9
mutter-3.30.1-4.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1632646 has been marked as a duplicate of this bug. ***