This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 1013299 - Unnecessary functionality should be locked down while screen is locked
Unnecessary functionality should be locked down while screen is locked
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: gnome-shell (Show other bugs)
19
All Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Daiki Ueno
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-29 03:22 EDT by Yohei Yukawa
Modified: 2015-02-17 12:24 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-17 12:24:03 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
You can launch set-up tool even when the screen is locked (317.72 KB, image/png)
2013-09-29 03:22 EDT, Yohei Yukawa
no flags Details

  None (edit)
Description Yohei Yukawa 2013-09-29 03:22:28 EDT
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
Comment 1 Daiki Ueno 2013-09-29 08:23:46 EDT
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.
Comment 2 Yohei Yukawa 2013-09-29 11:05:55 EDT
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,
Comment 3 Daiki Ueno 2013-09-29 14:14:55 EDT
(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
Comment 4 Yohei Yukawa 2013-09-29 17:17:52 EDT
> 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,
Comment 5 Fedora End Of Life 2015-01-09 15:01:31 EST
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.
Comment 6 Fedora End Of Life 2015-02-17 12:24:03 EST
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.

Note You need to log in before you can comment on or make changes to this bug.