GDM is specifically written so that the focus never leaves the username/password entry field.  This is because in the normal case, you don't want to navigate through the widgets. 

Note that none of the "other" widgets that show up are really necessary.  The user can access most buttons by hitting F10 to get to the menu, and the "OK" and "Start Again" buttons are more for convenience.  You can obviously hit <Return> or <Tab> to do the same thing as "OK".  "Start Again" is a convenience thing.  it is only useful if you entered an incorrect username and are at the password entry, but typing a password for an invalid username will cause it to also go back to "Username" entry.

Note bug #127339 asked to make Tab act like Enter.  So do we now undo this change?  

Perhaps we need to get someone from usability, like Calum, to comment on how this should work?

Created attachment 87147 [details] [review]
Allow normal buttons keynav for a11y

Ah. I've read your comment, Brian, after attaching a fix. As it stands, I'm happy either way, but it does seem that having unfocusable buttons seems to be a bit nonstandard.

Patrick:

To be honest, I also don't feel strongly either way.  I think the current behavior is to make GDM more usable for the common case.  99.99% of the time, users just want to type in their username and password and log into their session.  So, by keeping focus in the username/password entry, it helps to facilitate quick navigation through the login process.

Perhaps users will change their session and language the first time they log in, but since these values are saved as "default" for the user, most users don't need to navigate the UI to change these values more than once.  Some users (who change session type or language type from time-to-time) would use these options more often, but such users are probably in the minority.

That said, if it makes sense to support navigating the UI with the Tab key (either to be more "standard" or for a11y reasons), then I think we should do the following:

1) Make the Tab key work for both gdmlogin and gdmgreeter.  Your patch only 
   makes it work for gdmlogin.

2) Make it possible to navigate the face browser via the keyboard as well.
   Note bug #412576 is about this and has a patch which I rejected because
   the technique used wasn't so good (too intrusive).  In that patch I suggest
   how this could be implemented without so much hackery.

3) Also note that the gdmlogin and greeter code is littered with calls to
   "gdm_widget_grab_focus (entry)" calls, which causes the entry field to get
   focus at specific times.  We should review these and make sure they all
   still make sense if we are changing how the UI works with focus.

If you wanted to tackle the above, and provide a patch that makes both
gdmlogin and gdmgreeter support Tab as UI navigation, then I'd be willing
to put this into 2.19 and see how many people scream that Tab no longer
works as it did before.  :)

I'll reserve judgement until I've looked at it properly, but another option would be to throw Ctrl+Tab into the equation somehwere... that's our usual "move the focus when you expect Tab to do something else" shortcut.  The question then is whether users actually do expect Tab to do "something else" in what is really just a regular text field (clearly one of them did in bug #127339), and thus whether they'd think of trying Ctrl+Tab at all...

I'd like to check out how some other login screens handle this before I offer a firm opinion, though :)

Calum, I am comfortable removing the ability for Tab to act like Enter if that seems like the right approach.  Although some users might like the fact that Tab can be used here, I think the advantage of being able to navigate the GUI has some merit.  Let me know what you decide.

So, a quick straw poll of the login screens I have around here:

Username field:
Old-style dtgreet (Solaris 10u2): Tab moves focus
New-style dtgreet (Solaris nv_64): Tab inserts tab char, Ctrl+Tab moves focus
Win98 (don't have XP/Vista handy): Tab moves focus
OSX: Tab moves focus

Password field:
Old-style dtgreet (Solaris 10u2): Tab moves focus
New-style dtgreet (Solaris nv_64): Tab does nothing
Win98: Tab moves focus
OSX: Tab moves focus

Suggests to me that we should keep Tab for moving focus (except where it's a valid entry field character, in which case use Ctrl+Tab for doing that). I'd think that would be the preferred solution from an accessibility perspective, too.

Thanks Calum. Brian?

I agree.  I think Tab should allow change focus.  Thanks Callum for your comments.  Fixing in head.

I see this as a local security hole.  Many users migrating from Windows will be used to typing the username-TAB-password-ENTER sequence.  Most will have it in muscle memory, so when they sit down at a gdm terminal they might type the same sequence without looking.  Now their password has just been typed in clear text into the username field for all around to see.  

I move that the TAB-ENTER relation be reestablished, and support the use of CTRL-TAB for people wanting to move between fields.

I agree that this is a concern, though we need to think about what is more important here.  

1) Supporting Windows users with muscle-memory issues.  
2) Supporting want to support accessibility.

The workaround for muscle memory issues isn't so bad, users just need to learn to use Enter which also works in Windows, and is probably a more sensible keystroke to be using anyway.

The issue I see with using CTRL-TAB is that it is a less common keystroke to use for changing focus since most programs just use TAB.  Some a11y users may not be aware of CTRL-TAB and may think that GDM doesn't allow users to change focus when they try TAB and see it doesn't work.

Personally, I think making GDM work best for a11y users is more important than supporting Windows migration, at least in this case where the workaround isn't too hard to get used to.

If you think this issue is serious, please open a new bug and we can discuss.

I fell into the trap several times now since username<TAB>password is definitely a programmed action-sequence in my hands.
It looks really obscene to see your password flash on the screen. I feel like an exhibitionist showing what should remain hidden.

BTW, I don’t see this as a Windows only issue, since I use U<Tab>P everywhere, especially on the web (webmailers, databases, bugtrackers, forums, just everywhere U<Enter>P would submit the form with an empty password).

And, in the Ubuntu-themed greeter there are no other widgets to tab-focus to. So what actually happens is that the username text is selected and subsequently overwritten. Wouldn't it be resonable to revert to the old behaviour for the themed greeter?

I don't quite understand the statements in this thread, and especially the suggestion that a11y support is somehow at odds with supporting Windows users.

Are there any objections to the following sequence:
 1. Initial focus is in the username field; user enters their username
 2. User presses the TAB key, which brings focus to the Password field (and perhaps quietly inserts an ENTER key to support distinct username/password authentication)
 3(a) User enters their password, and presses the ENTER key - and is authenticated; 
 - or -
 3(b) User enters their password (or not), and presses the TAB key, which brings focus to the other controls in the login GUI

Peter:

Remember that the username and password field are the same entry field.  After you type your username, the same entry field is used for entering the password.
So your suggestion that TAB brings focus from the username to password field is really suggesting that the focus stays in the same entry field.

Also remember that GDM just relies on PAM to ask the user whatever PAM wants.  In the "normal" case this is username, then password.  However, for some PAM modules it may not ask for username at all (such as with SmartCard), or it may ask for more than 2 things (e.g. a PAM module that also asks for domain).  There is no interface for GDM to know much about what PAM wants to do, so GDM doesn't know how many entry fields PAM will ask for or which one is the last question PAM will ask for.  So, any solution that depends on GDM knowing such things would be hacky and prone to not working properly.  Some programs try to grep
the query string that PAM asks for to try to figure out what step it is, but
this tends to break since the strings are not consistent across distros or
PAM modules.

So, in short, I don't think any solution that makes TAB work one way for some steps in the PAM authentication and a different way for other steps is really workable.

I wasn't trying to suggest that we are really "at odds" with supporting Windows users.  The issue here is the following:

- A11y users expect TAB to switch focus to other widgets in the GUI.
- Some Windows users expect TAB to act like ENTER since Windows authentication
  works this way.

You can't have both.  One solution is to use CTRL-TAB for switching 
focus and TAB acts like ENTER.  This would make Windows users happier, but 
would mean that a11y users would need to know to use CTRL-TAB to switch focus.
Since CTRL-TAB is less frequently used than TAB, this probably would mean some
a11y users wouldn't realize that they can switch focus in GDM.  A second
solution is just to use TAB for focus change and Windows users need to relearn
that they shouldn't use TAB here.  I can't think of any other solutions that
are workable, though I'm happy to hear more suggestions.

I neglected to mention but as belshazzar has pointed out this is not merely a
windows issue.  Just about every computer authentication system (including web
forms, Apple OSX, KDM) relies on the username TAB password convention.  I
realise that both Windows and web browsers get it wrong too, in that they both
use ENTER to submit incomplete login forms instead of shifting focus to the
password field.

If you stick with the current two-screen system and don't change the TAB key
behaviour you *will* get unintended password disclosure.  I have already seen
this happen with several users in our labs, which has lead to us considering
ditching GDM or GNOME entirely.

Brian Cameron raises a good point that we don't want to mess with the PAM
sequence too much, therefore if CTRL-TAB is an unacceptable way of 'TAB'bing
between fields, then there is little other option but to have the username and
password fields displayed simultaneously on the one screen like everyone else.

Greg:

Unfortunately displaying both username and password at the same time breaks the PAM model as well.  Since we don't know how many fields PAM will ask for (as explained above PAM may not request username if SmartCard is used), it isn't possible for GDM to display both entries at the same time.

I do agree password disclosure is a bad thing, though I'm not sure I agree that just because other login programs work a certain way this means all login programs should work the same way.  

Since this bug is generating so much discussion, I am re-opening the bug and changing the synopsis to indicate that the bug is regarding tab versus ctrl-tab.  I think someone from usability should consider the discussion and decide what we should do here.  Either way we solve this problem, I think, we make things annoying for some users.  

Calum is a GNOME usability expert, and is cc:ed on this bug, so hopefully he will add some thoughts here.

Brian:

Thanks for reminding me about how PAM works.

I'm still confused about the problems here though...  On all desktops, we are increasingly moving away from a GUI with both username & password text entry fields in them, in which you Tab from username to password.  The new convention is a faces-like authenticator where you choose the user from a list of users (at least in non-enterprise login scenarios).  This has been the case in Windows and Macintosh for a long time - just how many users are going to be hit by this problem?

Also, if TAB really did bring the user to a new control (vs. inserting a TAB character and requiring Ctrl-TAB), then in the case that is being complained about in this bug, focus would be commonly on a non-text control, and the password then entered by the "non-observant user" would not be displayed on the screen in the username field.  This should thus make the complaint much less severe...

Belshazzar: on my Ubuntu 7.4 system, I would move TAB to the "Options" menu which is otherwise not particular discoverable by a blind keyboard user.

GDM does support a Face Browser, but it is off by default.  If users want to select users via a "click on the face picture" mechanism, then this can be turned on.

However, there are security issues with exposing usernames, and not all systems would want to provide a face browser approach to selecting username.

Thanks for talking me through the TAB'ing issue.  Yes, you are right, hitting TAB should move focus to one of the buttons, so that if you start typing it shouldn't enter text into the entry widget.  I looked at the code and gdmlogin had a problem where it was not allowing focus to enter the buttons.  I fixed this, so this should eliminate the problem of exposing usernames.  gdmgreeter was working okay already.

So this problem should now be fixed.  It's still perhaps annoying that Tab doesn't work like Enter for some users, but at least passwords will not be exposed.

I think this corrects the more improtant issue.  We can still discuss the virtues of how Tab versus Ctrl-Tab should work with moving focus in GDM, but the security issue is now gone.

I found this bug because I encountered the password disclosure problem. I guess, the package of my distribution (version 2.19.3-0ubuntu1) is just not fresh enough to see the fix mentioned in comment #18.

I'd like to state that Ctrl+TAB should be fine from an a11y point of view. If you write an email in evolution for example, you also have to CTRL+TAB to change focus. This is no secret and should be known by users who don't use the mouse for example. As it was already pointed out, changing language settings and similar tasks are just not as common as just logging in.

I also found this bug after the tab key ceased to "enter" my username and switch to the password field.

I agree with Christof and the others that prefer the tab key to submit the username and move focus to the password entry field. I feel that it is the most common method for username and password entry, and I think that users would be more comfortable with this functionality.

It does seem to be the concensus that people would like Ctrl-Tab to be the focus switching key.  Would someone provide a patch to make this change for review?

Note that there was a bug in earlier 2.19 releases that caused the tab to never move to the buttons in gdmlogin.  Now that this is fixed in the latest 2.19 release, this shouldn't cause the password to get revealed anymore.

*** Bug 464039 has been marked as a duplicate of this bug. ***

Just a quick note to confirm that this new behaviour is really annoying, because the U<tab>P sequence is used literally *everywhere* eg: to login into this bugzilla system, I used U<tab>P. I understand the technical concerns with PAM etc. but simple cases should simply work...

(Interesting problem!)

I'd like to note that we're only discussing this issue due to the ubiquity of User/Password login dialogs and the fundamental difference there is between interacting with PAM and an User/Password login dialog.

I think there are two approaches to try to help users typing tabs out of this situation:
1) emulate a login/password dialog and try to adapt the behavior of this dialog with the underlying PAM system; for example start by presenting login and password text entry (allowing entry in both) and trigger sending of the login when one tries to switch from the login to password field with tab or when enter is pressed; next try some heuristics to send the password to PAM is the PAM message looks like a password prompt (e.g. ends in "assword")

pros: looks like a standard login/password prompt in most cases
cons: looks weird in the other cases and requires kludges and heuristics

2) keep the current PAM-aware presentation but try to play nice with people trying to type tab; for example send the login to PAM if the user presses tab and the login text field isn't empty, but switch focus to the next widget if the login text field isn't empty

pros: keeps the PAM model and still allows for a11y
cons: still requires some careful kludges (for example it's likely that only the first PAM should be handled this way as the password message could very well be empty -- but then you wouldn't want to press "tab" to mean "enter" if your login or password is blank.


I frankly prefer 2), but then 1) might be the sexiest solution from a non-technical end-user perspective.


I have a coupel of questions:
a) how do you handle tab in a password?  (I guess tab in a login isn't really used)
b) how comes the password is displayed when one types login, tab, password?  Does it mean there's a single widget or that keypresses for all widgets land in the PAM dialog box?

PAM has the restriction that it handles one thing at a time.  First username, then password.  Since PAM modules can be used to support very different things (such as SmartCard or fingerprint reader), you can't really make assumptions about what information PAM will ask for.  Therefore any solution that makes such assumptions breaks PAM.  It might be okay for GDM to be configured to allow such special features (such as asking for username and password together) if people are using the PAM-common-case, but such features would need to be configured so they could be turned on or off to avoid breaking PAM modules that don't work this way.  Does this make sense?

It seems that lots of people really care about this.  If someone were to care enough to write a patch to change the behavior of gdmlogin and gdmgreeter so that Ctrl-Tab changes focus and Tab acts as Return, then provide a patch and I'll commit it.

You can look at the code from older versions of GDM to see how we used to make Tab act as Return.  Adding code to make Ctrl-Tab act as focus change probably is similar.

Created attachment 96948 [details] [review]
Let tab act like enter only when PAM entry field isn't empty

(In reply to comment #25)
> PAM has the restriction that it handles one thing at a time.

Yes, I do understand this restriction; I'm even using libpam-thinkfinger (fingerprint scanner on thinkpads) since some months!

> It might be okay for GDM to be configured to
> allow such special features (such as asking for username and password together)
> if people are using the PAM-common-case, but such features would need to be
> configured so they could be turned on or off to avoid breaking PAM modules that
> don't work this way.  Does this make sense?

Well, instead of checking for the "PAM-common" case, I proposed heuristics instead (see my previous comment), but I'm not fan of any of these solutions.

> It seems that lots of people really care about this.  If someone were to care
> enough to write a patch to change the behavior of gdmlogin and gdmgreeter so
> that Ctrl-Tab changes focus and Tab acts as Return, then provide a patch and
> I'll commit it.
> 
> You can look at the code from older versions of GDM to see how we used to make
> Tab act as Return.  Adding code to make Ctrl-Tab act as focus change probably
> is similar.

Certainly, here's the proposed patch implementing the second proposal I made (make tab act like enter only when the PAM entry field isn't empty).

Loic, thanks for the patch.  I'm not sure, though, that I like this idea.  I'd prefer for Tab and Ctrl-Tab to work consistently.  Remember that blind users depend on keyboard navigation and I'd expect that most blind users would find such inconsistent behavior to be really confusing.

I'd recommend that if we want to change things we should make Tab always act like Return and Ctrl-Tab always change focus.  This is more following the UI spec.

Brian, I think what you describe was the previous behavior of gdm as it tested for the ctrl, shift, mod flags in the event and only filtered it when these weren't set; my guess is that ctrl-tab wasn't filtered, and I can tell it isn't filtered with the proposed patch.

If I provide another patch without the entry field checks, it will basically be the previous version of the code; is that what you would like?

Yes, if ctrl-tab acts as expected and changes focus as Tab does currently with that change, I'll accept that change and revert the code to the old code in the 2.20 branch.

Created attachment 97055 [details] [review]
Let tab act like enter only when PAM (old behavior of gdm)

Loic, I just tested your patch and it doesn't seem to work properly.

It seems when gdmlogin or gdmgreeter start, hitting Tab moves focus to the next widget (e.g. the OK button).  Only if focus is in the enter field (like when you are in the middle of typing something in it) does it accept this as return.

I suspect this is because the key_release_event handler is only attached to the entry field.  In older versions of GDM, this worked because GDM had code that forced focus to always remain on the entry field, but that code is gone now that people with a11y needs want the ability to move focus around.

So I think this patch works as follows:

+ If you hit Tab when focus is on the entry field then it is return.
+ If you hit shift-tab when focus is on the entry field then it shifts focus
+ If you hit Tab or shift-tab when the focus is on any other widget, then it 
  shifts focus.

This seems broken.  Do you also see this behavior.  Do you think you could make the code work a bit better?

I think what you describe is how the patch works, yes; what you describe didn't horrify me but I guess what you would prefer is that tab always acts like return, even when the focus isn't in the entry field.

In my experience, there apps with overrides for particular widgets which will then behave differently for certain keys and override the default keybindings of the user or of the rest of the application.

I'm not sure whether the consistency of having tab act like return for all widgets is really a benefit for the end-user.  What I see is that end-users can still use tab / ctrl-tab as much as it is possible (so always except when in the entry field) and only in the login field will tab act like enter, to please user who want such a local override.

The use case for "tab acts like enter" is "username" + tab + "password", it's not really "username", select some random other widget, press tab and then type your pasword, IMO.

(In reply to comment #32)

> The use case for "tab acts like enter" is "username" + tab + "password", it's
> not really "username", select some random other widget, press tab and then type
> your pasword, IMO.

Agreed. I think this is the behaviour we want, as it seems very reasonable. It works as if there were two entry fields like on a webpage or on other common systems’ login windows.

As a further datapoint, I'll notice that the username + tab + password works again in Ubuntu Gutsy since the last 2 days; so the Ubuntu guys have probably locally reverted to the old GDM behaviour as well.

(In reply to comment #34)
> As a further datapoint, I'll notice that the username + tab + password works
> again in Ubuntu Gutsy since the last 2 days; so the Ubuntu guys have probably
> locally reverted to the old GDM behaviour as well.

Yes, I applied the first patch I attached to this bug in the Ubuntu package; there were reports complaining of the exposure of their passwords, while we did not receive any a11y issues on the subject (that I know of); but after the release, we should resync with upstream.

Okay, thanks.  I agree with you now that you have explained things.  This patch is now in the 2.20 branch and in the 2.20.1 release.

(In reply to comment #36)
> Okay, thanks.  I agree with you now that you have explained things.  This patch
> is now in the 2.20 branch and in the 2.20.1 release.

(BTW, let me know if you change your mind on letting tab act like usual when the login field is empty.  I think it makes widgets behave sensibly except when someone just typed is login, after what one is not expected to try to navigate to another widget, but to send the login to PAM.)