Greeter doesn't select user's last session when using "Other"

Bug #1031421 reported by Andrew Ayer
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
LightDM GTK Greeter
Fix Released
Low
Unassigned
lightdm-gtk-greeter (Debian)
Fix Released
Unknown

Bug Description

When you enter a username by hand (i.e. not via the user list), lightdm-gtk-greeter doesn't select the user's last session (or language). However, if you enter an incorrect password, *then* your last session *is* selected.

Since your last session is only selected when entering an incorrect password, this also means that if you select a desired session and then enter the wrong password, your choice will be reset to whatever your last session was, which is unexpected. This also happens when logging in via the user list.

The attached patch (also in BZR at lp:~agwa/lightdm-gtk-greeter/lightdm-gtk-greeter) fixes the problem by selecting the user's last session at the time the user is selected (either via the user list or by hand), rather than at the the time the password is entered.

Revision history for this message
Andrew Ayer (agwa) wrote :
Revision history for this message
John Paul Adrian Glaubitz (glaubitz) wrote :

Hi Andrew,

thanks for the patch, I was actually starting to look at the problem and wanted it to fix as well. Even I would have preferred to simply be able to explicitly choose the last session and last language in lightdm(-gtk-greeter) like you could in gdm 2.20.

Also, please have a look at my related bug reports:

- bug #1071417 - Inconsistent behavior when restoring default session and language
- bug #1068853 - Inconsistent behavior when storing default session and language
- bug #1069494 - Please allow to choose between AccountsService and ${HOME}/.dmrc

which show that there are several problems when dealing with saving and restoring the last session or language. This mechanism is broken especially when relying on network logins with users changing their login machines on a daily basis.

Cheers,

Adrian

Revision history for this message
John Paul Adrian Glaubitz (glaubitz) wrote :

Hi Andrew,

I applied and tested your patch today and it does indeed restore the last session and language which is a good start.

However, I'd still prefer to have the options "Last Session" and "Last Language" like gdm 2.20 did it. Furthermore, gdm 2.20 would ask you if you wanted to store the selected session and language if they do not match the ones stored in .dmrc which allows you to choose a different session and language just once with changing your default settings.

Adrian

Revision history for this message
Andrew Ayer (agwa) wrote :

Hi Adrian,

I agree with you - I think the gdm 2.20 behavior is better.

This patch was more about taking the behavior the lightdm devs intended and making it work with minimal changes, so there would at least be *some* way to reliably select the last session. Unfortunately, it has been 3 months now and there hasn't been a peep from any lightdm devs...

Andrew

P.S. Thanks for the links to the other bug reports - I guess it's worse than I thought!

Revision history for this message
Lionel Le Folgoc (mrpouit) wrote :

(Blame launchpad for changing some settings, and so I wasn't receiving bugmail anymore from launchpad projects)

I guess the current code in lightdm-gtk-greeter is buggy in that aspect (I mostly test it with the userlist on Xubuntu these days), so feel free to provide a nicer patch like gdm-2.20 if you prefer, I have no problem to include it (as long as it doesn't need .dmrc directly, since dealing with Accountsservice and .dmrc is lightdm's job).

Changed in lightdm-gtk-greeter:
importance: Undecided → Low
Revision history for this message
Yves-Alexis Perez (corsac) wrote :

Actually, with the current code, it seems that the only saved state if the selected item in the menus. Correct me if I'm wrong, but here's the behavior:

- at lightdm-gtk-greeter startup, selected items are the first in the menu (for session and language)
- if the user select something in the menu, the relevant function (set_session() or set_language()) are called
- when the username entry looses focus and the username field is non NULL, authentication is started (start_authentication())
- the function calls set_session (lightdm_user_get_session (user)) (ditto for language), erasing the previous choice
- if the user re-select a session before validating the password, it'll work since set_session() will be called again

I guess one fix would be to actually check if a session is not already selected before setting it in start_authentication(). That would require keeping a state, but just local to lightdm-gtk-greeter, as far as I can tell.

Revision history for this message
Yves-Alexis Perez (corsac) wrote :

Actually, selecting an item in the menu does only that, it doesn't call set_session() at all. It's when something else call set_session() than a check is done about the menu items (to see if it exists, and set it active if needed). And set_session() with an item is actually only ever called by start_authentication() is called.

That means nothing can set a state variable, unless a callback is added to the menuitems, which might be possible, although I'm not sure how to do it.

Revision history for this message
Yves-Alexis Perez (corsac) wrote :

Here's a pretty rough patch, which /seems/ to work fine for me. Can you comment on it? It's more or less my first attempt at GTK+ at all, so…

Changed in lightdm-gtk-greeter (Debian):
status: Unknown → Confirmed
Revision history for this message
Sean Davis (bluesabre) wrote :

This patch seems to work well. I've added it to trunk.

Changed in lightdm-gtk-greeter:
status: New → Fix Committed
Changed in lightdm-gtk-greeter (Debian):
status: Confirmed → Fix Released
Sean Davis (bluesabre)
Changed in lightdm-gtk-greeter:
milestone: none → 1.7.0
Sean Davis (bluesabre)
Changed in lightdm-gtk-greeter:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.