Description of problem: in F29, trying to input using Japanese(kana kanji) in oowriter. when I start typing in Japanese(Hiragana) and press space for candidates suggestion, I get the candidates window as expected. However if I select a candidate and hit enter to commit that word, no input is entered. Experiencing this with libreoffice applications and nautilus. Version-Release number of selected component (if applicable): F29 ibus-1.5.19-4.fc29.x86_64 How reproducible: always Steps to Reproduce: 1. open oowriter 2. using kana kanji input method, start typing any Japanese input. 3. press space for candidate suggestion window. 4. from the candidate suggestion window, select a candidate at any position and hit enter to commit it. Actual results: No input is entered. Expected results: The input should get committed. Additional info: The input is working properly in gedit. It works in libreoffice as well if direct input is entered by hitting enter, without candidate window.
I think ibus-hangul's behavior is right, it needs to hide the preedit text before commit the text. But I think ibus-kkc has an unnecessary updating preedit before commit the text and it can be fixed in ibus-kkc.
Given that imwayland has been used since F28, and neither ibus-kkc nor libkkc package has changed since then, isn't it a regression in gtk/gnome-shell? Is there any reasonable argument why this needs to be (not "could be") fixed in ibus-kkc side?
Sorry I think I proposed the wrong bug.
Note: This bug happens when the lookup window is shown besides the preedit text. The workaround would be to use ibus-anthy.
(In reply to fujiwara from comment #4) > Note: This bug happens when the lookup window is shown besides the preedit > text. It is obvious from the description; no need to repeat. What I was asking was if there is any good reason we should fix it in ibus-kkc rather than in gtk/gnome-shell. In F28 I had to fix bug 1577031 in ibus-skk, because: - the proper fix would require rework of protocol routing in those components - it was the first release where the protocol routing was introduced so it's not surprising that there is such limitation For this particular case, is there any obstacle that prevents fixing it in gtk/gnome-shell?
(In reply to Daiki Ueno from comment #5) > (In reply to fujiwara from comment #4) > > Note: This bug happens when the lookup window is shown besides the preedit > > text. > > It is obvious from the description; no need to repeat. Ah, I mean to clarify the bug description for the users and GNOME maintainers but not you. > In F28 I had to fix bug 1577031 in ibus-skk, because: > - the proper fix would require rework of protocol routing in those components > - it was the first release where the protocol routing was introduced so it's > not surprising that there is such limitation Not sure why you note the bug. I didn't pay attention to that bug because I cannot reproduce it. Seems ibus-skk has not been changed in f28 and upstream. Did you it? > > For this particular case, is there any obstacle that prevents fixing it in > gtk/gnome-shell? As I noted this and bug #1632981 are same root cause and I think the best way is to fix GTK and I linked the upstream bug in #1632981 but I'm not sure if it's on time for f29. I leave this bug because I think updating preedit before committing text is not necessary in ibus-kkc. This bug is up to you and you may like to comment something in the upstream bug.
(In reply to fujiwara from comment #6) > As I noted this and bug #1632981 are same root cause and I think the best > way is to fix GTK GTK or Wayland server. I didn't get the fix yet.
(In reply to fujiwara from comment #6) > (In reply to Daiki Ueno from comment #5) > > (In reply to fujiwara from comment #4) > > > Note: This bug happens when the lookup window is shown besides the preedit > > > text. > > > > It is obvious from the description; no need to repeat. > > Ah, I mean to clarify the bug description for the users and GNOME > maintainers but not you. How would that be useful in this context? > > In F28 I had to fix bug 1577031 in ibus-skk, because: > > - the proper fix would require rework of protocol routing in those components > > - it was the first release where the protocol routing was introduced so it's > > not surprising that there is such limitation > > Not sure why you note the bug. I provided an example I had to fix in the engine side, rather than the client side (gtk/gnome-shell). Was it unclear from the context? > I didn't pay attention to that bug because I > cannot reproduce it. Seems ibus-skk has not been changed in f28 and > upstream. Did you it? It was fixed in libskk, because the key event handling of ibus-skk is mostly implemented in libskk. > > For this particular case, is there any obstacle that prevents fixing it in > > gtk/gnome-shell? > > As I noted this and bug #1632981 are same root cause and I think the best > way is to fix GTK and I linked the upstream bug in #1632981 but I'm not sure > if it's on time for f29. > > I leave this bug because I think updating preedit before committing text is > not necessary in ibus-kkc. That is what I am asking for, and was unclear until now. On this bug you didn't note that it has the same root cause as bug 1632981, and you even suggested a different fix in comment 1, without any reasoning. That was really confusing.
(In reply to Daiki Ueno from comment #8) > How would that be useful in this context? I think it's useful to note that the lookup window needs to be shown besides preedit since this bug is not reproduced with preedit only and actually I couldn't carry down the problem exactly internally. > That is what I am asking for, and was unclear until now. On this bug you > didn't note that it has the same root cause as bug 1632981, and you even > suggested a different fix in comment 1, without any reasoning. That was > really confusing. I added the see also bug. Probably the confusion would happen because: > Is there any reasonable argument why this needs to be (not "could be") fixed in ibus-kkc side? I didn't think I need to answer this question but yourself could have the responsibility to fix this bug for f29 or not. But the blocker flag was typo. And you replied my second comments which I noted for users and GTK maintainers while I'm confident that you could reproduce the bug.
(In reply to fujiwara from comment #9) > (In reply to Daiki Ueno from comment #8) > > How would that be useful in this context? > > I think it's useful to note that the lookup window needs to be shown besides > preedit since this bug is not reproduced with preedit only and actually I > couldn't carry down the problem exactly internally. If the target audience was the GTK maintainers, you should have mentioned that in your upstream bug, not here; I still don't see any point of your second comment, because no one from the GTK team is on the CC list of this bug. > I added the see also bug. That's too implicit. You could have noted here as well that those two are not only related, but also have the same cause.
(In reply to Daiki Ueno from comment #10) My messages are not for you, sorry.
*** This bug has been marked as a duplicate of bug 1632981 ***