Bug 33777 - "Tab" key invokes TraverseListener on the Shell
Summary: "Tab" key invokes TraverseListener on the Shell
Status: RESOLVED WONTFIX
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 2.1   Edit
Hardware: PC Linux-Motif
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform-SWT-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-03-04 12:43 EST by Konrad Kolosowski CLA
Modified: 2003-03-04 20:07 EST (History)
1 user (show)

See Also:


Attachments
simplified ContextHelpDialog.java (1.59 KB, text/plain)
2003-03-04 17:24 EST, Konrad Kolosowski CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Konrad Kolosowski CLA 2003-03-04 12:43:19 EST
2.1 RC1 motif build.
org.eclipse.help.ui.internal.ContextHelpDialog registers TraverseListener with 
Shell.  The listener is called when "Tab" key or "Shift-Tab" key combination is 
pressed.  It shoud not be invoked for these keys.
Comment 1 Steve Northover CLA 2003-03-04 14:43:25 EST
This is not actually a bug.  The detail indicates that the key might be used 
as mnemonic which would be strange for Tab, but no illegal.
Comment 2 Konrad Kolosowski CLA 2003-03-04 14:57:16 EST
This behavior occurs on F1 help infopop that does not have any mneumonics set 
as far as I know.
Why is the listener called on motif, while it is not called on Windows?
Comment 3 Steve Northover CLA 2003-03-04 15:02:58 EST
Where is the keyboard focus?  There are differences between platforms when 
SWT.ON_TOP is used when creating a shell.  Can you append a snippet that shows 
the problem to this PR?  Thanks.
Comment 4 Konrad Kolosowski CLA 2003-03-04 17:24:00 EST
Created attachment 3836 [details]
simplified ContextHelpDialog.java

This bug together with bug 33776 cause a problem for help, where pressing Tab
on the F1 infopop causes focus to traverse all focusable widget and then gets
lost (pressing Tab more times does not bring it back).	On the other hand
Shift-Tab works O.K.

If you run the attached snippet on Windows you will notice that
TraverseListener is not called when Tab is pressed, and everything works fine. 
If you run it on Motif, Tab will bring move focus to the second button, and
next gets lost.  The TraverseListner is being called with doit set to false. 
If you comment out registering of a listener, everything magically works again.


I have temporarily fixed a problem for help by adding a workaround that sets
doit to true inside the listener, but according to my consultation with Felipe,
the handler should not be called at all.
Comment 5 Steve Northover CLA 2003-03-04 20:07:52 EST
The "commenting out of the listener" bug has been fixed by Felipe.  The fact 
that you are getting a traverse for a Tab character on Linux is also fixed.