GNOME Bugzilla – Bug 684650
When there's only one user, pressing enter should trigger the password text dialog
Last modified: 2012-10-24 14:18:55 UTC
Hi When there's only one user, on boot, if I press enter, nothing happens. On gdm 3.4 it would select the only user and open the password text dialog, now it does nothing. Now you need to click on the user name and then the password dialog will show. Can we get back this behaviour? thank,
The login screen is implemented in gnome-shell, moving this there
git-bisect says it's caused by: be290fafe7ff8abbecdeb760f8adc0de28466558 is the first bad commit commit be290fafe7ff8abbecdeb760f8adc0de28466558 Author: Giovanni Campagna <gcampagna@src.gnome.org> Date: Tue Sep 4 20:47:20 2012 +0200 ScreenShield: wait for stage mapping before taking a grab In gdm, we would attempt to become modal during the synchronous initialization, and this would fail, as X prevents grabs on unmapped windows. Instead, wait for the stage to be visible before becoming modal. https://bugzilla.gnome.org/show_bug.cgi?id=683357
Created attachment 225165 [details] [review] screenShield: Connect to the actor's show signal instead of using BEFORE_REDRAW This should make sure that we grab at the right time while at the same time not break focus handling.
*** Bug 684850 has been marked as a duplicate of this bug. ***
If there are multiple users, arrows could move selection up/down then enter does the slow animation to type password. Mouse shouldn't be required to log, IMO.
Ideally we wouldn't show the user list when there is only one user - we'd jump straight to the password entry stage.
In the case of only one user, could we have the option of logging to a started session locked? so when the user unlocks with the password everything is already started?
(In reply to comment #7) > In the case of only one user, could we have the option of logging to a started > session locked? so when the user unlocks with the password everything is > already started? I don't think you would like that. Imagine me going around your computer and turning it on. Suddenly you appear online on the IM network, without you knowing. Or it starts seeding torrents. Or whatever.
Review of attachment 225165 [details] [review]: Thanks for working on this. I don't think this patch is quite right. When running it, I see this in my log: JS LOG: pushModal: invocation of begin_modal failed and then later JS ERROR: !!! message = '"incorrect pop"' JS ERROR: !!! fileName = '"/usr/share/gnome-shell/js/ui/main.js"' JS ERROR: !!! lineNumber = '638' JS ERROR: !!! stack = '"popModal([object _private_St_Widget])@/usr/share/gnome-shell/js/ui/main.js:638 ()@/usr/share/gnome-shell/js/ui/screenShield.js:805 wrapper()@/usr/share/gjs-1.0/lang.js:204 (0)@/usr/share/gnome-shell/js/ui/screenShield.js:563 wrapper(0)@/usr/share/gjs-1.0/lang.js:204 ([object _private_Gio_DBusProxy],null)@/usr/share/gnome-shell/js/ui/screenShield.js:413 ([object _private_Gio_DBusProxy],[object _private_Gio_SimpleAsyncResult])@/usr/share/gjs-1.0/overrides/Gio.js:193 which I believe is probably the problem the commit in comment 2 was originally trying to fix. ::: js/ui/screenShield.js @@ +570,3 @@ // otherwise X errors out + let actorShownId = 0; + actorShownId = this.actor.connect('show', Lang.bind(this, function() { I think the "show" signal will get emitted on line 581 right below, so this is equivalent (I believe) to just moving that code outside of a callback.
Created attachment 225864 [details] [review] gdm: Try harder to move focus to the first user _moveFocusToItems is to be called to early causing clutter_actor_grab_key_focus not to be called. So queue another attempt at idle when this happens to make sure we actually move the focus sucessfully.
Could we focus the last logged-in user instead of the first user in the list? (assuming they are sorted alphabetically and not in last-logged-in fashion) Use case: You have two users, "guest" and "peter". You use "peter" 99% of the time ("guest" is just for visitors), but "guest" is the first user in the list and you always have to move the selection, which is slightly annoying in the long run.
(In reply to comment #11) > Could we focus the last logged-in user instead of the first user in the list? > (assuming they are sorted alphabetically and not in last-logged-in fashion) If we want to do that we should just sort by "last login in".
thats a separate issue, we shouldn't confuse this bug with it
Created attachment 225868 [details] [review] gdm: Try harder to move focus to the first user _moveFocusToItems seems to be called to early causing clutter_actor_grab_key_focus not to be called. So queue another attempt at idle when this happens to make sure we actually move the focus sucessfully. --- Fix commit message.
Review of attachment 225868 [details] [review]: Should this be a BEFORE_REDRAW rather than an IDLE? That is, is it possible it gets delayed enough that the user actually keynavved away? Otherwise it is fine to commit.
Attachment 225868 [details] pushed as 3ed5f9c - gdm: Try harder to move focus to the first user Pushed a version which uses BEFORE_REDRAW instead of just idle.
Kamil, the list is sorted by login frequency. So the one on top is the 95% case.
Thanks for info, Ray. That's great.
(In reply to comment #9) > Review of attachment 225165 [details] [review]: > > Thanks for working on this. I don't think this patch is quite right. When > running it, I see this in my log: Ray, you seem to have pushed this patch: http://git.gnome.org/browse/gnome-shell/commit/?id=bdeb7d86 even though we already had this fixed with http://git.gnome.org/browse/gnome-shell/commit/?id=3ed5f9cd15e ... accident?
woops, probably pushed something else while this was still lingering on my branch, i'll take care of it.