Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 53143

Summary: Keyboard navigation in GUI user entry window not sane.
Product: [Retired] Red Hat Linux Reporter: Mike McLean <mikem>
Component: anacondaAssignee: Brent Fox <bfox>
Status: CLOSED RAWHIDE QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-09-27 19:22:38 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Michael A. McLean 2001-09-04 14:51:55 UTC 
* re0831.0-i386 (and previous ones as well)
* any GUI install or upgrade

Description of Problem:

This is really a minor thing, but I thought I would report it.

In the user entry window of the gui installer, keyboard navigation can be a
little unclear and the user may not be sure where they are in the window.

To be precise, the tab order of the window appears to be:
User name -> Full Name -> Password -> Confirm -> Ok -> Cancel -> User name --->

However:
 - no cursor appears in the windows unless the user does a mouse-over, even
after the user begins typing.
 - Button selection is unclear.  The ok button is not highlighted when it
is selected.  The only visual clue is that the Cancel button ceases to be
highlighted.
 - The arrow key behavior in the button pane is strange.  One would expect
that the left and right arrow keys would move between the two buttons in
the pane, but this is not the case.  The left arrow does nothing, and the
right arrow has the same behavior as tab.
Comment 1 Michael Fulbright 2001-09-04 18:34:01 UTC 
Something to consider for the next release.
Comment 2 Brent Fox 2001-10-24 17:45:30 UTC 
Using the Gtk Dialog with GTK 2.0 instead of Gnome Dialog avoids this behavior,
so this is fixed in cvs now.  Thanks for your report.