Bug 1632981

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. ***