This seems to affect not only mr-itrans but many (if not all?) input methods.

I just tried ibus-kkc, ibus-table, ibus-typing-booster, they all
have that problem on F21 Beta TC3 although they disabled
the input correctly in password fields on F20.

In ibus-table, I have a function

    def do_set_content_type(self, purpose, hints):
        if self._has_input_purpose:
            self._input_purpose = purpose

which sets the input purpose. Then in the key event handler, the input
purpose can be checked and if it is IBus.InputPurpose.PASSWORD or
IBus.InputPurpose.PIN the key event handler can just pass the key event
through.

On Fedora 20, this function do_set_content_type() is called
when the lock screen entry widget gets focus, on Fedora 21 it is
never called.

<fujiwara> I tried live desktop 20141014 but I cannot reproduce the screen lock
           issue.

I also tried

https://kojipkgs.fedoraproject.org//work/tasks/929/7860929/Fedora-Live-Workstation-x86_64-21-20141014.iso

now and installed to disk.

I can confirm that the problem does *not* occur then.

But it *does* occur with Fedora-Workstation-netinst-x86_64-21_Beta_TC3.iso.

Discussed at 2014-10-15 freeze exception review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2014-10-15/f21-blocker-review.2014-10-15-16.04.log.txt . Accepted as a freeze exception (at least) - obviously this shouldn't happen! And can't be fixed with an update for live images.

If it works in nightlies we would expect it will work in TC4. Can you please test TC4 (or RC1, if that's what it turns out to be) when it arrives? Thanks!

Let's set this ON_QA to reflect that we're expecting it to be fixed in TC4...

I tried Fedora-Workstation-netinst-x86_64-21_Beta_TC4.iso now
and could *not* reproduce the problem there.

Very weird, has anything changed here between TC3 and TC4?

https://fedorahosted.org/rel-eng/ticket/6010#comment:7 were the only blocker/FE changes. However, TC3 was built on 10-09, and Beta freeze was 10-14; TC4 has five days of regular 'stable' pushes compared to TC3. You'd have to look at the daily reports to see what went in on those days.

If this isn't happening in TC4 let's close it for now as it rather indicates something that went stable between TC3 and TC4 fixed this. If someone can reproduce on TC4 or later, please re-open with details. Thanks!

Hi 

I have tested it again on Fedora-Live-Workstation-x86_64-21_Beta-1.iso and found that problem still exists for Marathi input method.

How reproducible:

Steps to Reproduce:
1. Select itrans as input method for Marathi language
2. Lock the screen
3. Try to unlock the screen with itrans input method 

Please find screenshot attached.

Created attachment 951685 [details]
password_visible for marathi(itrans) input method

(In reply to anish from comment #9)
> Created attachment 951685 [details]
> password_visible for marathi(itrans) input method

I can reproduce that for all ibus-m17n input methods
(marathi(itrans) is one of the ibus-m17n input methods).
For example, it also happens with the Latn-Post input method which
is another one from ibus-m17n.

But that problem exists already in Fedora 20.

(In reply to Mike FABIAN from comment #10)

> But that problem exists already in Fedora 20.

https://bugzilla.redhat.com/show_bug.cgi?id=1024071

gnome-screensaver should disable input method in password entry
https://bugzilla.gnome.org/show_bug.cgi?id=619058

(In reply to A S Alam from comment #12)
> gnome-screensaver should disable input method in password entry
> https://bugzilla.gnome.org/show_bug.cgi?id=619058

Actually it seems fixed on the side of gnome-screensaver because
“input purpose” is set somehow.

Most ibus input engines do something like ibus-table does in this
commit:

https://github.com/kaio/ibus-table/commit/c5a60f60578f681059e821f476e8e9f61102718d

I.e. they check the input purpose and if it is “PASSWORD”
or “PIN” they disable themselves.

ibus-m17n doesn’t yet seem to do that.

(In reply to Mike FABIAN from comment #13)
> (In reply to A S Alam from comment #12)
> > gnome-screensaver should disable input method in password entry
> > https://bugzilla.gnome.org/show_bug.cgi?id=619058
> 
> Actually it seems fixed on the side of gnome-screensaver because
> “input purpose” is set somehow.

gnome-screensaver is no longer relevant, the lock screen and unlock dialog have been in gnome-shell for a while now.

That said, the input_purpose should still be correct for password entries[0].


[0] https://git.gnome.org/browse/gnome-shell/tree/js/ui/shellEntry.js#n53

Beta is signed off, no point being a Beta FE any more. Instead proposing as a Final blocker, under the security criterion - https://fedoraproject.org/wiki/Fedora_21_Final_Release_Criteria#Security_bugs , "The release must contain no known security bugs of 'important' or higher impact according to the Red Hat severity classification scale which cannot be satisfactorily resolved by a package update (e.g. issues during installation)."

Discussed at 2014-11-05 blocker review meeting [1]. We have punted the decision on this. We would like more information on this, because the bug has been around since F20.

Mike, can you tell us how commonly is the affected input method used? Is there a good chance this can be fixed in ~ two weeks? Is any other place affected, or just the gnome unlock screen?

Thanks.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2014-11-05/

(In reply to Kamil Páral from comment #16)
> Discussed at 2014-11-05 blocker review meeting [1]. We have punted the
> decision on this. We would like more information on this, because the bug
> has been around since F20.
> 
> Mike, can you tell us how commonly is the affected input method used? Is
> there a good chance this can be fixed in ~ two weeks? Is any other place
> affected, or just the gnome unlock screen?
> 
> Thanks.
> 
> [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2014-11-05/

I think the ibus-m17n input methods are not that common, so this 
does not need to be a blocker bug.

I don’t know ehther other places affected.

Ueno San already made a patch:

https://bugzilla.redhat.com/show_bug.cgi?id=1024071#c2

I just testetd that patch and it fixes the problem indeed.

Ueno San updated the ibus-m17n package:

https://bugzilla.redhat.com/show_bug.cgi?id=1024071#c3

I tested the package on Fedora-Live-Workstation-x86_64-21_Beta-4.iso
and it does indeed fix the problem.

*** This bug has been marked as a duplicate of bug 1024071 ***