Created attachment 804626 [details] You can launch set-up tool even when the screen is locked Description of problem: Currently ibus-kkc exposes unnecessary functionality even when the screen is locked Version-Release number of selected component (if applicable): Clean installed Fedora 19. How reproducible: 100% Steps to Reproduce: 1. Log in 2. Lock screen 3. Select "設定" from the menu of ibus-kkc exposed by gnome-shell Actual results: Nothing appears, but the setting dialog is actually launched in the user desktop. The user will see it when he/she actually unlocks the screen. Expected results: This functionality should be hidden and disabled while the screen is locked. Additional info: Basically we should carefully design IME functionality that is available on log-in screen and/or locked screen. For instance, we should disable following features to secure user privacy and prevent DOS attack. - Feature that directly or indirectly updates user dictionary - Feature that directly or indirectly exposes user dictionary - Feature that directly or indirectly updates user input history - Feature that directly or indirectly exposes user input history
There is nothing much IME can help on this. Maybe better ask gnome-shell to hide the preference menu? For the user dictionary and input history issues, that's not the case for F19, as IME doesn't even get focus on the password entry. Those features might be eventually needed when IME is used on kiosk, but that's another story.
Thank you for the info. Changing the Component to gnome-shell. > For the user dictionary and input history issues, that's not the case for F19, > as IME doesn't even get focus on the password entry. > Those features might be eventually needed when IME is used on kiosk, > but that's another story. I'm a bit confused about this. In GNOME bug 691392, you refereed to Fedora bug 891835 as follows. https://bugzilla.gnome.org/show_bug.cgi?id=691392 > It might be useful if "input-purpose" and "input-hints" properties can be set > on StEntry, like GtkEntry. Particularly to disable IM on lock screen: > Bug 891835 - gnome-shell screensaver should disable input methods for password input > https://bugzilla.redhat.com/show_bug.cgi?id=891835 And Fedora bug 891835 relies on the exactly same reprosteps to this issue. https://bugzilla.redhat.com/show_bug.cgi?id=891835 > Steps to Reproduce: > 1. enable ibus input method, eg "Japanese (anthy)" and select it as Input Source > 2. lock gnome > 3. try to enter passwd As you said, that might not be the case for F19. But please let me double check about the responsibility of an input method engine on lock screen in upcoming releases of Fedora. Could you please tell me which is the expected behavior? a. An input method engine never gains focus on the locked screen. If it can gain focus, it's a bug of gnome-shell not the input method engine. b. An input method engine never gains focus on the locked screen. If it can gain focus, it's a bug of gnome-shell not the input method engine. Apart from that, an input method engine has to handle the "input purpose" attribute for other cases. c. An input method engine may gain focus even on the locked screen. Even when the IME gains focus, it's not a bug of gnome-shell. The IME has to handle the input purpose in such case. You said "a." is correct in F19. Is this true even on F20 and rawhide? From IBus upstream, I recently got a reply that implies to me that design change to "b." or "c." might be approaching. https://groups.google.com/forum/#!topic/ibus-user/mvCHDO1BJUw > Now each engine has to handle the input purpose. > ibus-anthy just returns FALSE at the moment if the input purse is password. > However some engines might like to handle it with other ways. > The set_content_type() returns the GTK+ input purpose and input hints. Do you know what actually happens? Such information should be definitely helpful for me to implement input purpose feature for ibus-mozc to resolve the following bug. https://code.google.com/p/mozc/issues/detail?id=199 Thanks,
(In reply to Yohei Yukawa from comment #2) > As you said, that might not be the case for F19. But please let me double > check about the responsibility of an input method engine on lock screen in > upcoming releases of Fedora. Well, if you are talking about unreleased version of Fedora, this should have been filed against "rawhide" instead of "19". I don't expect the feature will be backported into the released version, though it is the IBus packager's decision to push 1.5.4 to F19. > Could you please tell me which is the expected behavior? > a. An input method engine never gains focus on the locked screen. > If it can gain focus, it's a bug of gnome-shell not the input method > engine. > b. An input method engine never gains focus on the locked screen. > If it can gain focus, it's a bug of gnome-shell not the input method > engine. > Apart from that, an input method engine has to handle the "input purpose" > attribute for other cases. > c. An input method engine may gain focus even on the locked screen. > Even when the IME gains focus, it's not a bug of gnome-shell. > The IME has to handle the input purpose in such case. > > You said "a." is correct in F19. Is this true even on F20 and rawhide? > From IBus upstream, I recently got a reply that implies to me that design > change to "b." or "c." might be approaching. As you observed, yes, we are changing the approach to handle this. The idea is to give more control of contextual behaviors based on the type of input fields. For instance, IME could switch the input mode to latin, when the focused input field is for phone number input. See: https://gitorious.org/libkkc/ibus-kkc/commit/8d9cfe6882f892ff936b20b986fab5d554715c96
> Well, if you are talking about unreleased version of Fedora, this > should have been filed against "rawhide" instead of "19". I don't > expect the feature will be backported into the released version, > though it is the IBus packager's decision to push 1.5.4 to F19. Thanks. I agree with you and this is why I put those things in "Additional info:" not "Expected results:". Anyway, it would be nice if the original issue described in "Actual results:" and "Expected results:" will be picked up by gnome-shell team as a case of F19. For the record, IBus 1.5.4 is about being pushed to F19. https://admin.fedoraproject.org/updates/FEDORA-2013-17357/ibus-1.5.4-1.fc19 > As you observed, yes, we are changing the approach to handle this. > The idea is to give more control of contextual behaviors based on the > type of input fields. That confuses me. According to your comment "Particularly to disable IM on lock screen" in https://bugzilla.gnome.org/show_bug.cgi?id=691392#c0, will we see "c." rather than "b." near future? If an IME has to honor "password" attribute, it is no longer an optional feature but a mandatory feature for such an IME. In other words, there is a huge gap between "has to handle" and "can handle" for an IME developer, especially on the password field that is used in a locked screen. Anyway, this might be an off-topic from the original post. I'll ask it in ibus-devel or somewhere if this thread is not appropriate to discuss it. Thanks,
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. 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 19 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 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 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 bug. Thank you for reporting this bug and we are sorry it could not be fixed.