Description of problem: When the input context is active on the application, it is disabled after the window the kinda notifications is popping up from the other application. once it happened, the trigger key doesn't work, even if the indicator says it turned off and on. It gets back after changing the focus. it is only workaround though, quite annoying so that it often happens. Version-Release number of selected component (if applicable): ibus-1.5.7-2.fc20.x86_64 How reproducible: always Steps to Reproduce: 1.turn on ibus 2.wait for the popup window is coming 3.type something Actual results: at 3, always ascii can be input, even though the indicate says IME is on. Expected results: should keeps working even after the popup window raised. Additional info: X atom properties the popup window has is like: _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW WM_WINDOW_ROLE(STRING) = "popup" _NET_WM_STATE(ATOM) = _NET_WM_STATE_SKIP_PAGER, _NET_WM_STATE_SKIP_TASKBAR _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NOTIFICATION WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, _NET_WM_PING
dunno if that helps, I use the sloppy mode as the window focus mode. after changing it to the click mode, I see the popup window takes a focus. just FYI.
Are you able to give a sample notification? I cannot reproduce your problem with xfce4-terminal in XFCE4 desktop. I tried "Click to focus" and "Focus follows mouse" in xfwm4-settings. I tried GtkWindow and NotifyNotification and works fine. --------------------------------- from gi.repository import Gtk from gi.repository import Notify Notify.init('test') notification = Notify.Notification(summary = 'Summary', body = 'Body', icon_name = 'ibus') notification.set_timeout(10 * 1000) notification.show() Gtk.main() --------------------------------- --------------------------------- from gi.repository import Gtk window = Gtk.Window(type = Gtk.WindowType.POPUP) label = Gtk.Label(label = 'test') window.add(label) window.show_all() Gtk.main() ---------------------------------
(In reply to Akira TAGOH from comment #1) > dunno if that helps, I use the sloppy mode as the window focus mode. after > changing it to the click mode, I see the popup window takes a focus. just > FYI. Sorry, false alarm. even on the click focus mode, after the window popped up, still can input on the application during keeping the window open. interestingly even if I turned off ibus on the application, can't turn on ibus after the window is popped up, until changing the focus. (In reply to fujiwara from comment #2) > Are you able to give a sample notification? let me try.
I can reproduce the following (I am not sure whether this is the same or not):
- Set Gnome to use “Click to Focus”. - In some terminal, type “sleep 10; gnome-terminal” - switch on ibus-kkc - In google-chrome, in the URL hit the “a” key every second ... - You see ああああ... in the URL bar - As soon as the gnome-terminal window pops up, it grabs the focus - continue hitting the “a” key. - Now in gnome-terminal one sees “aaaa...”, *not* “ああああ...” even though the input method indicator in the gnome panel still says あ. - Moving the focus from the gnome-terminal somewhere else and back fixes the problem, typing “a” now inserts “あ”. I *cannot* reproduce this if I use firefox instead of google-chrome‽
The problem of google-chrome is that google-chrome sends focus-in and focus-out events again after gnome-terminal sends focus-in event. Are there similar applications besides google-chrome?
There might be an issue in Chrome. just filed a bug http://code.google.com/p/chromium/issues/detail?id=411788 though, maybe unlikely because it works with uim say.
See also https://code.google.com/p/chromium/issues/detail?id=351991
I decided to fix the bug in ibus side. However I think the delayed focus-in/focus-out is not correct and it would be a bug in chrome.
ibus-1.5.9-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/ibus-1.5.9-2.fc20
ibus-1.5.9-2.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/ibus-1.5.9-2.fc21
Package ibus-1.5.9-2.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing ibus-1.5.9-2.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-11959/ibus-1.5.9-2.fc21 then log in and leave karma (feedback).
Even if upgrading ibus to 1.5.9-2, the issue still persists.
(In reply to Akira TAGOH from comment #13) > Even if upgrading ibus to 1.5.9-2, the issue still persists. I cannot reproduce your problem in f20 and f21. Since I use a VM host, I use mouse to change windows. Do you use google-chrome?
(In reply to fujiwara from comment #14) > (In reply to Akira TAGOH from comment #13) > > Even if upgrading ibus to 1.5.9-2, the issue still persists. > > I cannot reproduce your problem in f20 and f21. > Since I use a VM host, I use mouse to change windows. > Do you use google-chrome? as per my comment at comment#9, yes. and the focus mode seems not relevant to this issue, because the popup window doesn't affect the current focus. see comment#3.
(In reply to Akira TAGOH from comment #15) > (In reply to fujiwara from comment #14) > > (In reply to Akira TAGOH from comment #13) > > > Even if upgrading ibus to 1.5.9-2, the issue still persists. > > > > I cannot reproduce your problem in f20 and f21. > > Since I use a VM host, I use mouse to change windows. > > Do you use google-chrome? > > as per my comment at comment#9, yes. and the focus mode seems not relevant > to this issue, because the popup window doesn't affect the current focus. > see comment#3. I cannot reproduce your problem. comment #5 is tested with ibus-1.5.9-2.
(In reply to fujiwara from comment #16) > (In reply to Akira TAGOH from comment #15) > > (In reply to fujiwara from comment #14) > > > (In reply to Akira TAGOH from comment #13) > > > > Even if upgrading ibus to 1.5.9-2, the issue still persists. > > > > > > I cannot reproduce your problem in f20 and f21. > > > Since I use a VM host, I use mouse to change windows. > > > Do you use google-chrome? > > > > as per my comment at comment#9, yes. and the focus mode seems not relevant > > to this issue, because the popup window doesn't affect the current focus. > > see comment#3. > > I cannot reproduce your problem. > comment #5 is tested with ibus-1.5.9-2. I cannot reproduce it anymnore either (ibus-1.5.9-2.fc21.x86_64 in Fedora-Workstation-netinst-x86_64-21_Beta_TC1.iso in qemu. So guess it is fixed.
Talking off line, I could reproduce your problem. In your case, chrome has one text entry and another popup context. 1. popup context take focus. 2. ibus delete the focus of text entry due to 1. 3. popup context lose focus. Then ibus does not bring back the focus of text entry. Either way can resolve your problem. 1. popup context should not take the focus. 2. text entry should call focus-in after popup context lose focus. for 1, you filed http://code.google.com/p/chromium/issues/detail?id=411788 Since I get the issue for the first time, I hope it will be fixed by chrome. If this problem is really critical, I can consider the fix in ibus. --- ibus-1.5.8/client/gtk2/ibusimcontext.c.orig +++ ibus-1.5.8/client/gtk2/ibusimcontext.c @@ -857,12 +857,7 @@ ibus_im_context_focus_in (GtkIMContext * } } - if (_focus_im_context != NULL) { - g_assert (_focus_im_context != context); - gtk_im_context_focus_out (_focus_im_context); - g_assert (_focus_im_context == NULL); - } - else { + if (_focus_im_context == NULL) { /* focus out fake context */ if (_fake_context != NULL) { ibus_input_context_focus_out (_fake_context); @@ -903,7 +898,6 @@ ibus_im_context_focus_out (GtkIMContext return; } - g_assert (context == _focus_im_context); g_object_remove_weak_pointer ((GObject *) context, (gpointer *) &_focus_im_context); _focus_im_context = NULL;
Well, it very often happens here and getting frustrated. if it can be quickly fixed that would be really appreciated.
OK, I will integrate that candidate patch in Fedora. I'm working on other patches currently.
Oops, forgot to add this in revision 6.
ibus-1.5.9-7.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/ibus-1.5.9-7.fc21
ibus-1.5.9-7.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/ibus-1.5.9-7.fc20
Package ibus-1.5.9-7.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing ibus-1.5.9-7.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-16630/ibus-1.5.9-7.fc21 then log in and leave karma (feedback).
ibus-1.5.9-8.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
ibus-1.5.9-8.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.