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 - Shift+tab does not go back in fields in gtk2 dialogs
Summary: Shift+tab does not go back in fields in gtk2 dialogs
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gtk2
Version: 8.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Owen Taylor
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-03-21 13:49 UTC by Pierre Sarrazin
Modified: 2007-04-18 16:52 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-06-10 22:28:54 UTC


Attachments (Terms of Use)

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.



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