Description of problem:
Inputting hangul marchs in place in gnome-terminal
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. launch gnome-terminal
2. input hangul (switch hangul, click any keys)
Actual results: click rrrrrr (with ibus-hangul)
Expected results: click rrrrrr (with ibus-hangul)
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.
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
Discussed during the 2018-10-08 blocker review meeting: 
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"
There is now a proposed fix for this, but it seems like it was a bit too simple and may need further work:
Discussed during the 2018-10-15 blocker review meeting: 
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.
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. ***