Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 86403

Summary: Shift+tab does not go back in fields in gtk2 dialogs
Product: [Retired] Red Hat Linux Reporter: Pierre Sarrazin <sarrazip>
Component: gtk2Assignee: Owen Taylor <otaylor>
Status: CLOSED UPSTREAM QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-06-10 22:28:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Pierre Sarrazin 2003-03-21 13:49:48 UTC
Description of problem:
The tab key moves from one field to another in a dialog,
but shift+tab does not go back, contrary to my expectations.

Version-Release number of selected component (if applicable):
gtk2-2.0.6-8
libgnomeui-2.0.3-3

How reproducible:
Every time.

Steps to Reproduce (for example):
1. Right-click on the panel
2. Add to Panel
3. Launcher...
4. Use tab to go from Name field to Generic name field.
5. Press shift+tab
    
Actual results:
The cursor stays in the Generic name field.

Expected results:
The cursor would go back to the Name field.

Additional info:
Ctrl+tab does not have a Ctrl+shift+tab equivalent either.

Comment 1 Owen Taylor 2003-03-21 14:12:35 UTC
This works in general.

What keyboard layout are you using? (the French-Canadian layout
is rather exotic when compared to other layouts, so it wouldn't
suprise me a lot if there was a problem with it in specific.)

Have you changed anything else about your keyboard configuration
(e.g., disabled XKB, created a .Xmodmap, etc.)

Is there anything else about your system that might be different
from a standard Red Hat 8 install?


Comment 2 Pierre Sarrazin 2003-03-22 01:00:14 UTC
> What keyboard layout are you using?

The 'qc-2' layout, but the 'qc' layout gives the same
result in the above scenario.

Interestingly, the 'us' layout gives a different but still
incorrect behavior: shift+tab goes to the next field,
just like tab alone.

The exact command that is used by the Keyboard Layout
Switcher Preferences applet to install the 'qc-2' layout
is 'gkb_xmmap qc-2'.  For the 'us' layout, it is
'gkb_xmmap us'.

Another data point: the 'us101' layout behaves like 'qc-2':
shift+tab does nothing.


> Is there anything else about your system that might be
> different from a standard Red Hat 8 install?

It is an upgraded Red Hat 7.2 system.

The Keyboard Layout Switcher Preferences applet in the panel
seems to correspond to the /usr/libexec/gkb-applet-2 process.
This executable comes from the gnome-applets-2.0.1-6 RPM,
which was built on porky.devel.redhat.com.

Under 'qc-2' as well as 'us', xev reports that:
- the tab key produces keycode 23 (keysym 0xff09, Tab);
- the shift+tab key produces keycode 50 (keysym 0xffe1, Shift_L)
  then keycode 23 (keysym 0xff09, Tab).


Comment 3 Owen Taylor 2003-06-10 22:28:54 UTC
Unfortunately, the GKB keymaps tend to be a little poorly maintained;
we'll eventually be switching to an applet called 'gswitchit' which
uses the keymaps distributed with XFree86.

See:

 http://bugzilla.gnome.org/show_bug.cgi?id=73423

for why the above doesn't work with GTK+.

 http://bugzilla.gnome.org/show_bug.cgi?id=82412

For fixing the GKB keymaps.