GNOME Bugzilla – Bug 657996
First / only user account not selected by default; have to use mouse to login
Last modified: 2021-07-05 14:20:28 UTC
In the old GDM, the first or only user account would be highlighted on the login screen - so you could just hit 'enter', type the password, and be logged in. In the new login screen, this isn't the case; hitting enter does nothing. You have to move the mouse to log in. Perhaps the optimal behaviour would be, if there was only a single user account, to select it automatically and go straight to password entry; if there are multiple user accounts, highlight the first by default, so keyboard navigation can be used easily to select the desired account. halfline says: "so there's two parts here, 1) initial focus is wrong 2) we don't queue key events if the user starts typing their password early"
we'd have to know if network login was enabled or disabled before auto picking the user which might be hard (the whole Not Listed? button think i mean). you should be able to just hit down arrow or tab or something to move focus, not use the mouse. You're right, though, we really need select the correct one by default.
*** Bug 660039 has been marked as a duplicate of this bug. ***
*** Bug 660054 has been marked as a duplicate of this bug. ***
*** Bug 660796 has been marked as a duplicate of this bug. ***
I haven't looked at the source myself, but I would assume there's an issue with putting the the "not listed?" below the password field?
that's an idea, we could "Not Ray?" or whatever
Yeah it would make more sense to say that. I figure the best way of implementation would be: - if only one is available, auto-choose a user along with a "Not Whoever?" option - if no user is available then it should right away show a field for a user name - if there's multiple available users, the current implementation would be good. For multiple users, it still would be a good idea to put the focus on the first user to avoid the misunderstanding that the user can't use the keyboard easily (like the misunderstanding of the OP)
Created attachment 199175 [details] [review] gdm: move focus to first item in list This allows the user to just hit when the user list first comes up (in many cases).
( attachment 199175 [details] [review] isn't a complete fix, just a small incremental improvement to the current situation )
Assuming it can make it into 3.2.1, it's a good fix until 3.4.x
Review of attachment 199175 [details] [review]: IRC review. ::: js/gdm/loginDialog.js @@ +310,3 @@ + + _moveFocusToItems: function() { + if (!this._hasItems()) { let hasItems = Object.keys(this._items).length > 0; if (!hasItems) return;
had a brief discussion with Jasper over the patch on irc: [19:49:42] <halfline> magcius: can you review the interim patch i posted for bug 657996 ? (since you've done so many other reviews for me today :-) [19:49:43] <bebot> Bug http://bugzilla.gnome.org/show_bug.cgi?id=657996 minor, Normal, ---, rstrode, UNCONFIRMED, First / only user account not selected by default; have to use mouse to login [19:49:49] <magcius> halfline, sure. [19:56:59] <magcius> halfline, I'm confused -- you don't set can_focus on this.actor, so why would it ever receive key focus? [19:57:19] <magcius> oh, because you do some setInitialKeyFocus shenanigans [19:57:43] <halfline> right, it's a sort of dummy widget that holds focus until an item is added [19:58:07] <halfline> but not a separate dummy widget, just reusing the main widget itself [19:58:29] <magcius> Why not set the key focus when the first item is added instead? [19:59:03] <halfline> i do [19:59:07] <halfline> that's the last hunk in the patch [19:59:22] <halfline> but i also do it any time focus is moved to the dialog (say ctrl-alt-tab) [20:00:40] <magcius> halfline, the widget doesn't have can_focus set -- it shouldn't ever retrieve focus. no? [20:02:39] <halfline> magcius: hmm [20:02:55] <halfline> one sec [20:02:56] <magcius> unless the ModalDialog code is doing something silly [20:07:40] <halfline> magcius: yea that top line of the patch may be completely bogus [20:07:44] <halfline> magcius: let me play a bit [20:12:51] <halfline> magcius: alright so the story is... [20:13:35] <halfline> can_focus is a shellism, and the focus can be moved to a can_focus: false actor explicitly using clutter api [20:13:46] <halfline> instead of say the shell navigate_focus api [20:13:58] <halfline> and that is happening here [20:14:07] <halfline> we set initial focus to a can_focus: false widget [20:14:15] <halfline> which is a little questionable [20:14:55] <halfline> but it's the reason (apparently) why i added that top line last night [20:16:06] <halfline> so if you want to say on the review that the existing setInitialFocus to can_focus: false widget is wrong, i won't argue with that [20:18:06] <magcius> We were already doing that. [20:18:14] <magcius> (but yes, it is wrong) [20:19:19] <magcius> halfline, so, does the top half do anything? [20:19:41] <halfline> yes, the key-focus-in signal is still emitted [20:19:52] <halfline> since key-focus-in is a clutter signal [20:20:03] <halfline> and clutter knows not of can_focus [20:22:32] <magcius> halfline, right, but when do we get the key-focus-in signal? [20:22:42] <magcius> when does the element retrieve key focus? [20:22:56] <magcius> st_widget_navigate_focus won't give it.... [20:23:28] <halfline> this.setInitialKeyFocus explicitly uses the clutter function (set_key_focus or something like that) [20:23:39] <halfline> not right away, but later when the dialog is getting opened [20:24:02] <magcius> which happens before the first item is added, right? [20:24:09] <magcius> so just focusing the first item explicitly should do it, no? [20:24:15] <halfline> no [20:24:54] <halfline> not necessarly [20:25:10] <halfline> let me look through the code for a second then i'll give you a more precise answer [20:25:48] <halfline> the _loadUserList function is called at LoginDialog construction time [20:26:05] <halfline> if the user manager is already loaded then it will populate the list immediately [20:26:28] <halfline> the dialog is opened shortly after its constructed [20:27:05] <halfline> loginDialog.connect('loaded', function() { loginDialog.open() }); inside main.js [20:27:31] <halfline> magcius: so the the initial focus will potentially get moved to the login dialog after the list is populated [20:28:20] <magcius> halfline, so the bottom half is doing nothing? [20:28:22] <halfline> if the user list isn't fully loaded yet though [20:28:31] <halfline> user manager [20:28:42] <halfline> then the open could happen before the user manager loads [20:29:17] <halfline> so in any given boot, one half of that patch will do nothing [20:29:36] <halfline> most boots the bottom half will do nothing [20:30:40] <magcius> halfline, OK. Only other thing: I'd rewrite _hasItems as "Object.keys(this._items).length > 0" and move it inline. [20:31:02] <halfline> sure [20:31:33] <magcius> Other than that, go for it.
(woops midair collision)
Comment on attachment 199175 [details] [review] gdm: move focus to first item in list Attachment 199175 [details] pushed as 39d1235 - gdm: move focus to first item in list
*** Bug 662282 has been marked as a duplicate of this bug. ***
Is there anything left here?
well we haven't done comment 5 yet
*** Bug 686299 has been marked as a duplicate of this bug. ***
cc me
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.