The problem is caused by '_askForUsernameAndBeginVerification' being
called multiply times. So when we click 'next', the old connected
function will also be executed.
After the login banner is shown and hidden, the first user
in the user list becomes non-reactive. This is because the
banner is given an opacity of 0, but still allocated.
This commit fixes that by hiding the banner explicitly.
https://bugzilla.gnome.org/show_bug.cgi?id=743370
Normally when a user uses the login screen to log in, the
login screen gets killed and the user session takes over
the display.
This doesn't happen for wayland sessions, though. Instead,
the login screen gets reset, and the wayland session is started
on another VT.
The greeter proxy object needs to be recreated after this reset,
since it's associated with state no longer coupled to the login
screen after the reset.
This commit moves greeter proxy creation to happen at reset time.
https://bugzilla.gnome.org/show_bug.cgi?id=743371
Frequently banner messages are longer than can reasonable
fit in a one column view, which leads to a smooshed layout.
This commit changes the layout to a two column view, with the
banner on the left and the prompt on the right, if the banner
message is long enough that it can't fit well above the prompt.
If there isn't enough space for two columns then we keep the
one column layout but add scrollbars.
https://bugzilla.gnome.org/show_bug.cgi?id=703972
The login screen supports showing a banner message which admins
can use to mention login rules or disclaimers.
This message only shows up currently if the user list is enabled.
Most people who want to show a banner message also want to disable
the user list.
This commit moves the banner message to display when the user is
prompted for login credentials instead of when showing the user
list. It also adds a scrollbar if the message is too long.
https://bugzilla.gnome.org/show_bug.cgi?id=703972
The login screen is pretty custom full screen container and the standard
layout managers aren't really a good fit for the kind of layout that's
happening. This will be even more problematic with upcoming changes
to login banners, so we need to switch techniques.
This commit moves login dialog over to using a custom allocate handler
that has specific domain knowledge of the parts of the login screen
and where they go.
https://bugzilla.gnome.org/show_bug.cgi?id=703972
If the user list is disabled and the user clicks cancel quickly enough
after typing their username, they can get in a state where the
auth prompt gets stuck in the insensitive state.
This is because the login dialog code makes the prompt insensitive
while while pam is processing the provided username, but the prompt
only makes itself sensitive again when it is hidden.
This commit makes it sensitive right before asking for a username again.
https://bugzilla.gnome.org/show_bug.cgi?id=740141
When a user logs in to a wayland session, we keep the login screen
running on the X server with the login screen running in a deactivated mode.
This commit makes sure it get reactivated when the user comes back to
the VT (from user switching, logout or just ctrl-alt-f1).
https://bugzilla.gnome.org/show_bug.cgi?id=726989
Loading the user list can be expensive, for instance when there is
a large number of users and/or their avatars have to be fetched over
the network. In case the user list is disabled anyway, there is no
point in doing that work just to hide it, so stop doing that.
https://bugzilla.gnome.org/show_bug.cgi?id=725905
Right now we queue populating the user list in the middle of setting
up the dialog actors. Of course, the actual population happens some time
later after going back to the main loop.
It's more logical to structure the code so the the actors are
instantiated first in one block and then other things after that.
This commit moves the user list population enqueuing operation to the
bottom of the constuctor.
https://bugzilla.gnome.org/show_bug.cgi?id=721868
In some cases we load the user list after going back
to main loop and in other cases we load the user list
right away (depending on if accounts service is ready).
In the case we load the user list right away we cause a
traceback because loading the user list forces a reset,
which then tries to reset actors which aren't instantiated
yet.
This commit ensures the user list is loaded after the constructor
finishes and the event loop runs irregardless of the accountsservice
state.
https://bugzilla.gnome.org/show_bug.cgi?id=721868
Right now we only show the session menu button when verifying,
but we should also show it when verification is failed or we
can end up in situation where the session menu disappears during
an authentication retry.
https://bugzilla.gnome.org/show_bug.cgi?id=707064
Right now, we rely on PAM to ask for the username if disable-user-list
is TRUE. This is suboptimal because it means we can't check if we
should show a session menu.
This commit changes disable-user-list==TRUE to ask for a username up
front, rather than have PAM do it.
https://bugzilla.gnome.org/show_bug.cgi?id=706607
This commit introduces a new BeginRequestType enum which gets
passed to the 'reset' signal to specify whether
a username should be provided to the begin() method and changes
the loginDialog to comply.
Currently, the signal only ever gets emitted with
AuthPrompt.BeginRequestType.PROVIDE_USERNAME
but that will change in the future when providing smartcard
support.
https://bugzilla.gnome.org/show_bug.cgi?id=683437
Right now we have two booleans that specify when user verification
is happening and when it succeeded, respectively.
This commit consolidates them into one AuthPromptStatus enumeration.
This clean up will allow us to check for verification failure more
easily.
https://bugzilla.gnome.org/show_bug.cgi?id=683437
The only time we ever call _reset directly is when
detecting changes to disable-user-list. We can implicitly
trigger a reset for this case, just as easily by calling
this._authPrompt.reset()
This commit makes that change for consistency and to make
it easier to adjust the authprompt workflow later.
https://bugzilla.gnome.org/show_bug.cgi?id=683437
There's quite a bit of duplicated code between the login dialog
and the unlock dialog dealing with the various signals from the
ShellUserVerifier.
This commit moves that duplicated code into the AuthPrompt.
https://bugzilla.gnome.org/show_bug.cgi?id=704707
Right now there is a lot of duplicated code between the unlock
dialog and the login dialog.
This commit moves the login dialog's auth prompt to a separate
class, so that it can (in a subsequent commit) be used by the
unlock dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=702308
A bug got introduced when moving the login dialog away from modal
dialog, such that it listens for escape key presses in a mouse
event handler instead of a keyboard event handler.
This commit fixes that code to correctly listen for key-press-event
instead of button-press-event.
https://bugzilla.gnome.org/show_bug.cgi?id=702308
Right now if disable-user-list is true we show it briefly, just so
that we can fade it out to the user entry.
This commit avoids the fade in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=704471
Now that we preallocate space for the prompt message there is
a lot of loose space between the entry and the buttons.
This commit helps tighten things up by getting rid
of the large top padding set above the login buttons.
https://bugzilla.gnome.org/show_bug.cgi?id=702308
