Bug 32717 - Accessibility; focus does not traverse around in F1 infopop
Summary: Accessibility; focus does not traverse around in F1 infopop
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: User Assistance (show other bugs)
Version: 2.1   Edit
Hardware: Power PC Windows 2000
: P3 normal (vote)
Target Milestone: 2.1 RC2   Edit
Assignee: Konrad Kolosowski CLA
QA Contact:
URL:
Whiteboard:
Keywords: accessibility
Depends on:
Blocks:
 
Reported: 2003-02-24 12:26 EST by Konrad Kolosowski CLA
Modified: 2003-03-05 11:39 EST (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Konrad Kolosowski CLA 2003-02-24 12:26:47 EST 
Pressing tab multiple times, results in focus following all links, and then 
getting lost.  It does not come back to the first link.  It is required to use 
Sthift-tab to get the focus back to the last link.  Shift-tab works O.K., i.e. 
when focus is on the first link, pressing the combination (twice) will bring 
the focus to the last link.
Comment 1 Konrad Kolosowski CLA 2003-02-25 15:30:30 EST 
Same problem on Solaris
Comment 2 Konrad Kolosowski CLA 2003-03-03 16:14:02 EST 
And Linux motif.
Comment 3 Konrad Kolosowski CLA 2003-03-03 18:21:41 EST 
The doit field of an traverse event is false when delivered to shell's traverse 
listener.  This is only the case when "Tab" is pressed.  When "Shift-Tab" is 
used the doit is true.  We do not change the doit, and the event gets canceled.
Comment 4 Konrad Kolosowski CLA 2003-03-04 12:02:57 EST 
These are SWT bugs.  The traverse listener should not be called at all when tab 
is pressed.  I have released a workaround in help to set doit to true.
Comment 5 Konrad Kolosowski CLA 2003-03-04 12:53:25 EST 
I have opened bug 33776, bug 33777, bug 33778 agains SWT regarding tab key and 
focus issues.
Comment 6 Konrad Kolosowski CLA 2003-03-05 11:39:04 EST 
The SWT bug 33776 has  been fixed.  I have tested today's nightly build, and it 
appears the the workaround is no longer needed.  I will remove it from our code.