Created attachment 669534 [details]
Description of problem: Not sure if this is an ibus, libreoffice, or KDE issue. However, if you bring up libreoffice writer and then ctrl-shift to enter Chinese, for example, but then change you focus to another window you can no longer enter Chinese in libreoffice. Other apps, such as konsole, continue to response "correctly".
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Ctrl-Sift and select input method.
2. Start libreoffice writer
3. Enter Chinese, for example
4. Move cursor to konsole and allow it to gain focus
5. Move back to libreoffice
6. Not possible to enter Chinese. Even restarting ibus doesn't help.
Additional info: See attached screen shots in sequence. Verified on "real" system as well as a VM
Created attachment 669536 [details]
Created attachment 669537 [details]
Created attachment 669538 [details]
Upon further testing I've found that the problem only exists on a system where KDE was installed after GNOME. I have a KDE only VM and the problem does not exist in that environment.
(In reply to comment #4)
> Upon further testing I've found that the problem only exists on a system
> where KDE was installed after GNOME. I have a KDE only VM and the problem
> does not exist in that environment.
Probably I don't think it depends on the installation.
When I use libreoffice on KDE, the behavior is different between f17 and f18.
In f17, neither set focus and unset focus event is called in XIM protocol with libreoffice.
In f18, set focus event only is called with libreoffice but both set focus and unset focus event is called with xterm and libreoffice has this problem but xterm does not have so probably I think this problem is caused by libreoffice.
The following is the stack from ibus-x11 with libreoffice:
#0 xim_set_ic_focus (xims=0x1510850, call_data=0x7fff8455e010) at main.c:417
#1 0x0000000000404fc3 in ims_protocol_handler (xims=0x1510850, call_data=
0x7fff8455e010) at main.c:791
#2 0x0000000000411dd5 in SetICFocusMessageProc (ims=0x1510850, call_data=
0x7fff8455e010, p=0x15505d4 "\002") at i18nPtHdr.c:883
#3 0x0000000000413924 in _Xi18nMessageHandler (ims=0x1510850, connect_id=2, p=
0x15505d0 ":", delete=0x7fff8455e16c) at i18nPtHdr.c:1752
#4 0x000000000040a98b in WaitXIMProtocol (dpy=0x14f3020, win=71303174, ev=
0x7fff8455e1a0, client_data=0x1510850 " \264a") at i18nX.c:512
#5 0x0000003028861dd1 in _gdk_events_queue () from /lib64/libgdk-x11-2.0.so.0
#6 0x0000003028861ebe in gdk_event_dispatch () from /lib64/libgdk-x11-2.0.so.0
#7 0x000000300a047a95 in g_main_context_dispatch ()
#8 0x000000300a047dc8 in g_main_context_iterate.isra.24 ()
#9 0x000000300a0481c2 in g_main_loop_run () from /lib64/libglib-2.0.so.0
#10 0x000000302814ab47 in gtk_main () from /lib64/libgtk-x11-2.0.so.0
#11 0x0000000000406342 in main (argc=2, argv=0x7fff8455e518) at main.c:1220
Transferring to libreoffice.
*** Bug 910954 has been marked as a duplicate of this bug. ***
FWIW, I installed only KDE in a VM and it still fails for me....
This still fails in F19 Beta TC2
FWIW, I have downloaded and tested LO 4.0.3 from the LibreOffice website and it is fixed in that version.....
Any chance of getting 4.X for F18 and/or F19 ASAP?
Sorry.... Just realized I had the wrong VM open....
F19 has LO 4.0.3 and the problem is fixed.
Any chance of getting this for F18
All the talk of KDE threw me off, this must be fdo#63802 which I fixed upstream. Yes I can backport that easily enough.
Great.... Look forward to testing soon.
libreoffice-18.104.22.168-7.fc18 has been submitted as an update for Fedora 18.
libreoffice-22.214.171.124-8.fc18 has been submitted as an update for Fedora 18.
This latest update has not fixed this issue. :-(
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libreoffice-126.96.36.199-7.fc18'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
libreoffice-188.8.131.52-8.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
Created attachment 756978 [details]
Screen shot showing problem is not fixed....
First, note that libreoffice-core-184.108.40.206-8.fc18.x86_64 has been installed looking at the output in konsole.
Next, note that Intelligent Pinyin is enabled by the appearance of the Chinese character on the systray.
楊 (yang) has been typed on the first line.
The mouse is then moved to konsole and focus is grabbed
Move back to libreoffice and type yang again..... no ibus, no Chinese.
I'm not sure why this bugzilla was closed in the first place. I note in #16 this has not been fixed. I also gave negative karma.
libreoffice-220.127.116.11-9.fc18 has been submitted as an update for Fedora 18.
Sorry to say that the latest version still does not fix this bug......
Same as #19 Comment
libreoffice-18.104.22.168-9.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
As mentioned above.... This release of libreoffice does *not* fix the reported problem. :-(
yeah, the catch is that one it gets into the list it gets stuck in the list for every update after that that supercedes the previous
out of resources for investigating backports for f18, sorry
The reported problem exists in F20-TC2 !
However, if I download and install LibreOffice from libreoffice.org the problem does not exist.
FWIW, the discussion on the "test" list suggests the problem is introduced by packaging of LibreOffice for Fedora.
This is an ongoing and annoying issue which I hope can be addressed. I dislike having to use the packages from LibreOffice.org.
upstream builds against KDE3, we build against KDE4, different upstream implementations of the two backends, i.e. not a packaging bug but probably a standard upstream bug, just not exposed in the upstream builds because there KDE4 is not included
So, are you saying that a fix for this needs to wait until upstream builds against KDE4? Nothing can be done until then?
OK.... Your answer on the test list clarified things a bit more. Thanks.
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 20 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.