Bug 86403 - Shift+tab does not go back in fields in gtk2 dialogs
Shift+tab does not go back in fields in gtk2 dialogs
Status: CLOSED UPSTREAM
Product: Red Hat Linux
Classification: Retired
Component: gtk2 (Show other bugs)
8.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Owen Taylor
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-03-21 08:49 EST by Pierre Sarrazin
Modified: 2007-04-18 12:52 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-06-10 18:28:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Pierre Sarrazin 2003-03-21 08:49:48 EST
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 09:12:35 EST
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-21 20:00:14 EST
> 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 18:28:54 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.