Password entry box is not defined as invisible in glade definition

[Ash]

There is a mistake in the lightdm-gtk-greeter.glade file.
There should be a property defined as <visibility>False</visibility>. This causes the entry box to be treated as a password field. Simply setting invisible_char and invisibale_char_set properties are not enough to cause the entry box to behave as an obscured password field.

[Simon Steinbeiß (ochosi)]

While I couldn't reproduce your issue, I don't think adding that additional definition can hurt. Fixed in trunk, rev 168.

[Ash (flubba86)]

Thanks Simon,

I am still trying to work out why this was only an issue for me, and did not seem to affect anybody else.

It had only started happening on my system about 3 months ago, Im guessing it was a libgtk3 update which caused the change in behaviour, but I searched the gtk+ git commits back through the last year, and also checked the Debian libgtk3 changelog and there is no mention of changing or fixing the entry box password behaviour.

On this GTK3 Docs page (https://developer.gnome.org/gtk3/3.4/GtkEntry.html) it clearly states that the only way for an entry box to be displayed as a password field is to have the Visibilty attribute set to False, which was not the case lightdm-gtk-greeter. It actually should never have been displaying correctly obscured at all.

I thought maybe it was something glade related, but there is nothing changed in the entrybox params parsing there either.
My last thought that it was a change in the way that Gtk.Builder constructs the entrybox, but as far as I can thell there is no change there either.

So I am at a loss, but is is working now. Im sure the issue would have cropped up for Ubuntu and Mint users in due time.

[Simon Steinbeiß (ochosi)]

I have to agree, it's somewhat of an odd issue.

Well there's more than one way to set an entry to be a password field, and maybe that's also part of the problem (although I don't have an explanation for it).

Anyway, thank YOU for supplying the patch for that bug!

[Till W. (tillw.)]

Just want to add that I am also affected by this bug. It is reproducible for me. After a fresh reboot, the first login attempt always has a password field without "obfuscation". When I enter a wrong password (or click "log in" leaving the password field empty), I get a correctly "obfuscated" password field on the consecutive login attempts.

I use finger print based authentication (fprint) as well. Maybe this is related to the problem somehow. (Enabled fprint/pam causes an extra message displayed at the login screen right below the password field.)

[Simon Steinbeiß (ochosi)]

@Till W.: We need to know what version of the greeter you're using.

[Till W. (tillw.)]

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 13.10
Release: 13.10
Codename: saucy

$ dpkg -l lightdm-gtk-greeter
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-===================-==============-==============-===========================================
ii lightdm-gtk-greeter 1.6.1-0ubuntu1 amd64 LightDM GTK+ Greeter

[Simon Steinbeiß (ochosi)]

As you can see above, this bug was fixed in lightdm-gtk-greeter 1.7.1. Since you're using an older version, it's not surprising you're still seeing it.

[Till W. (tillw.)]

Thank you for pointing this out, Simon. I have now upgraded to version 1.8.3-0ubuntu1 (taken from Ubuntu trusty) and can no longer reproduce the bug.