After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 684650 - When there's only one user, pressing enter should trigger the password text dialog
When there's only one user, pressing enter should trigger the password text d...
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: login-screen
3.5.x
Other Linux
: Normal normal
: ---
Assigned To: Ray Strode [halfline]
gnome-shell-maint
: 684850 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-09-23 08:16 UTC by javiermon
Modified: 2012-10-24 14:18 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
screenShield: Connect to the actor's show signal instead of using BEFORE_REDRAW (1.29 KB, patch)
2012-09-25 19:12 UTC, drago01
needs-work Details | Review
gdm: Try harder to move focus to the first user (1.25 KB, patch)
2012-10-05 08:03 UTC, drago01
none Details | Review
gdm: Try harder to move focus to the first user (1.25 KB, patch)
2012-10-05 10:24 UTC, drago01
committed Details | Review

Description javiermon 2012-09-23 08:16:15 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,
Comment 1 Matthias Clasen 2012-09-23 14:49:00 UTC
The login screen is implemented in gnome-shell, moving this there
Comment 2 Ray Strode [halfline] 2012-09-24 21:59:18 UTC
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
Comment 3 drago01 2012-09-25 19:12:59 UTC
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.
Comment 4 Ray Strode [halfline] 2012-09-28 14:26:21 UTC
*** Bug 684850 has been marked as a duplicate of this bug. ***
Comment 5 Xavier Claessens 2012-09-28 15:09:55 UTC
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.
Comment 6 Allan Day 2012-10-02 13:26:04 UTC
Ideally we wouldn't show the user list when there is only one user - we'd jump straight to the password entry stage.
Comment 7 javiermon 2012-10-02 13:33:23 UTC
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?
Comment 8 Kamil Páral 2012-10-02 14:26:30 UTC
(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.
Comment 9 Ray Strode [halfline] 2012-10-02 21:42:36 UTC
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.
Comment 10 drago01 2012-10-05 08:03:33 UTC
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.
Comment 11 Kamil Páral 2012-10-05 08:29:08 UTC
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.
Comment 12 drago01 2012-10-05 09:35:14 UTC
(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".
Comment 13 Matthias Clasen 2012-10-05 10:06:13 UTC
thats a separate issue, we shouldn't confuse this bug with it
Comment 14 drago01 2012-10-05 10:24:26 UTC
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.
Comment 15 Giovanni Campagna 2012-10-06 16:07:56 UTC
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.
Comment 16 drago01 2012-10-06 16:15:40 UTC
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.
Comment 17 Ray Strode [halfline] 2012-10-22 15:24:53 UTC
Kamil, the list is sorted by login frequency.  So the one on top is the 95% case.
Comment 18 Kamil Páral 2012-10-22 15:57:24 UTC
Thanks for info, Ray. That's great.
Comment 19 drago01 2012-10-24 07:54:07 UTC
(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?
Comment 20 Ray Strode [halfline] 2012-10-24 14:16:23 UTC
woops, probably pushed something else while this was still lingering on my branch, i'll take care of it.