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
commit ea02380c15 changed the login
dialog to not use ModalDialog anymore. There's still one lingering
setInitialKeyFocus method call in the source, which will cause an
exception to be thrown when users have their user list disabled.
This commit fixes that.
https://bugzilla.gnome.org/show_bug.cgi?id=703874
There are some issues with the existing session menu. First, it looks
kinda bad. It seems like it's hanging around there, but it doesn't really know
what to do with itself.
Second, when it expands down it requires that the buttons below move
down with it. This kind of movement is awkward and looks a bit weird.
Third, its current position makes the "dialog" tall and unwieldy when
you add things like messages for fingerprint readers or authentication errors.
This commit moves the session list to a menu behind a button to address
the above problems.
Based on a patch by Jasper St. Pierre.
https://bugzilla.gnome.org/show_bug.cgi?id=702818
Right now, there's a weird flicker at start up where the
Not Listed? button shows up before the user list, which looks
pretty bad if you're watching for it.
This commit fixes that problem by hiding the Not Listed button
initially and showing it at the appropriate time.
https://bugzilla.gnome.org/show_bug.cgi?id=703132
The login screen is no longer even remotely dialog-like, so
using ModalDialog is pretty weird. It also makes it difficult
to put the session list in the same place as the spinner.
This commit moves loginDialog away from using modal dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=702818
The optional logo on the login screen is currently shown in the
top bar, which is not only a rather unprominent position, it also
gives the wrong suggestion of a clickable element.
Newer designs call for the logo to be shown horizontally centered
at the bottom of the screen, so implement that instead.
https://bugzilla.gnome.org/show_bug.cgi?id=694912
For classic mode, we want to use a different styling for the spinner,
so we will pick up the image filename from CSS to make use of mode
specific styling. As the CSS will give us a full pathname, adapt the
API to take a full pathname instead of building it inside AnimatedIcon
from the passed basename.
https://bugzilla.gnome.org/show_bug.cgi?id=693688
Right now, if multiple messages come in, they just sort of
clobber each other.
This commit sets up a message queue, and introduces pauses
long enough for the user to hopefully be able to read those
messages.
https://bugzilla.gnome.org/show_bug.cgi?id=694688
Right, the common code between the login screen and
the unlock screen handles clearing the user verifier
when GDM sends a reset.
We don't actually always want to clear the messages on
reset in the unlock case, though, so doing it implicitly
is problematic.
This commit moves the clear() call from the common code
to the specific reset handlers.
https://bugzilla.gnome.org/show_bug.cgi?id=694688
Some of the conditions for showing the user list were not
properly inverted, causing the session list to be hidden
when it shouldn't be and shown when it shouldn't be.
https://bugzilla.gnome.org/show_bug.cgi?id=694784
We disable the entry after a user answers a question while we
process it, but we don't reactivate it later if asked another
one.
This commit makes sure the entry is always reactive when we
are waiting for an answer from the user.
https://bugzilla.gnome.org/show_bug.cgi?id=691806
The user list and the "Not Listed?" button get shown and hidden at the
same time, so we can simplify the code by putting them in a new
subcontainer.
This commit creates a userSelectionBox container that both actors get
put in, and changes all the code that shows and hides these actors to
show and hide userSelectionBox instead.
https://bugzilla.gnome.org/show_bug.cgi?id=694062
The sessionList and the prompt hint are all really
part of the prompt, so we should have the code that
hides those things in hidePrompt instead of in
showUserList.
This commit does that.
https://bugzilla.gnome.org/show_bug.cgi?id=694062
Right now, when a user item is clicked we remove all other users from
the list and position the item in the appropriate place on screen.
Ultimately, we're going to want to crossfade from the fully populated
list to the user prompt. Since we're going to need to show the user
avatar in two different positions we can't simply move it.
This commit leaves the user item for the user list, and instead shows
a UserWidget actor during user verification, in the same way the
unlock dialog shows a UserWidget actor during reauthentication.
https://bugzilla.gnome.org/show_bug.cgi?id=694062
Right now we very abruptly kill the login screen
and start the users session without any transition
out.
This commit introduces a fade out of the dialog and
panels.
https://bugzilla.gnome.org/show_bug.cgi?id=694062
The latest mockups don't animate between states by
resizing actors. Instead, crossfades are employed.
This commit strips out many of the existing animations
as a first step toward implementing the new ones.
https://bugzilla.gnome.org/show_bug.cgi?id=694062
Since commit 1ae0fadbf4 we
no longer start a PAM conversation as soon as the user clicks
the "Not Listed?" button. Instead we defer starting the PAM
conversation until the user types their username.
Unfortunately, the cancel button resets the dialog back to the
user list indrectly by cancelling the current PAM conversation.
This means if the user hasn't yet entered thier username then
the cancel button doesn't work.
This commit performs a direct dialog reset in the case the
PAM conversation hasn't been started yet.
https://bugzilla.gnome.org/show_bug.cgi?id=693756
In a gdm session, we may not know what mouse orientation the user
may be in, so it makes sense to support both the left and right
mouse buttons to activate login or other items.
Additionally, add the behavior to all modal dialog items, even in
a user session, because it's unlikely that the user will right-click
on buttons, and it makes for an easier implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=688748
Due to limitations and bugs in SpiderMonkey's GC, wrapper objects
for cairo contexts and similar may not get cleaned up immediately
after repainting, leading to leaking memory. Explicitly disposing
of such objects after they're not needed can clean up large portions
of memory for cairo surfaces.
https://bugzilla.gnome.org/show_bug.cgi?id=685513
We need to do a better job of indicating login process. This can
sometimes take a few seconds (particularly if you get your password
wrong): we need to give better feedback of what's going on.
This adds a spinner next to the login button if the authorization takes
some time.
https://bugzilla.gnome.org/show_bug.cgi?id=687113
The login dialog had these issues:
- the entry was not really disabled, you could still edit text
- the sensitivity state was not reset on verification failure
- the session list was not disabled
The unlock dialog had these issues:
- "Login as another user..." was not insensitive
- redundant password char setting, overwriting the one given by the
question
The entry insensitive style was also wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=687113
For now we just use it to assign an identifier to modal modes in
which we want to allow some keybindings, but we don't use it for
any actual filtering; we'll start doing this shortly.
https://bugzilla.gnome.org/show_bug.cgi?id=688202
If I click on "Not listed?" in the login screen, I come to a username
field with two buttons: "Cancel" and "Sign In".
Clicking on "Sign In" doesn't actually sign me in though - it takes me
to the login entry. It would be better to rename "Sign In" to "Next" for
the username stage, therefore.
Gdm emit a signal to ask a question or a secret, but we can not know if
this is the last authentication question, hence we only use "Sign In"
for secret questions which improve the situation a lot.
https://bugzilla.gnome.org/show_bug.cgi?id=687656
In some deployments showing a user list at the login
screen is undesirable.
GDM's fallback login screen has a configuration key:
org.gnome.login-screen disable-user-list false
that causes the user-list to get hidden.
This commit adds similar functionality to the normal,
shell-based login screen.
Based on a series of patches by Marius Rieder.
https://bugzilla.gnome.org/show_bug.cgi?id=660660
Right now when a user clicks "Not Listed?" they end up
seeing a session list that gets reset after they enter their
username.
This commit hides the session list until the username has
been entered.
https://bugzilla.gnome.org/show_bug.cgi?id=660660
For the "Not Listed?" case we will need to be able
to identify when the user has entered their username.
Once we have a way of tracking when the username is
entered, we can then defer showing the session list
too early, before the user can reliably pick a
session.
This username tracking will also be important for
implementing a disable-user-list configuration key.
If the config key gets toggled off at runtime, we'll
need to know if we're at a disruptive part of
the authentication process or not, so we know whether
we can can expose the user list right away, or wait
until the authentication conversation finishes.
Right now, we pass null in for an initial username,
and let the PAM machinery ask the user, which means we
have no good way of knowing when the username is entered.
This commit changes the "Not Listed?" code to ask the
user their username up front, before starting the PAM
conversation in much the same way we do if the user
picks a user from the user list.
https://bugzilla.gnome.org/show_bug.cgi?id=660660
You can't login until something has been entered in the password field.
We should therefore make the login button insensitive until you have
entered some text.
https://bugzilla.gnome.org/show_bug.cgi?id=687112
When the user has the entered the password for the second time
and clicked OK, clear messages from the previous attempt, so any
new failure is shown clearly.
https://bugzilla.gnome.org/show_bug.cgi?id=687132
GDM has a 'logo' key in its schema to allow distributors to add
some branding. It is currently placed above the user list, which
no longer works too well since the login screen lost its dialog
window. Display the logo in the top-left corner instead of the
Activities button instead.
https://bugzilla.gnome.org/show_bug.cgi?id=685852
Check an environment variable, GDM_GREETER_TEST. If 1, LoginDialog will
skip anything that fails outside a GDM session.
It is therefore possible to test the GDM greeter without installing it
system-wide, by attempting login as the already logged in user (uses the
same code path as the unlock dialog).
https://bugzilla.gnome.org/show_bug.cgi?id=683725
Adding a group to the Ctrl-Alt-Tab popup will also add it to the
focus manager. Due to that, we currently end up with two focus
groups added for the login dialog - an explicit one for the entire
dialog, and an implicit one for the main content group.
When doing keynav, we ascend in the widget hierarchy from the
currently focused actor until we find a valid focus root, so
adding a children of the dialog as focus root breaks keynav to
any actors that are not inside the main content group.
The simple fix is to use the same group in both cases.
https://bugzilla.gnome.org/show_bug.cgi?id=684730
Now that we use a different text style for the username depending on
whether the user list is expanded or not, changing the :expanded style
before the actual transition looks disruptive. Adding the style right
before fading in other items and removing it right after fading them
out gives a better result.
https://bugzilla.gnome.org/show_bug.cgi?id=685201
