SUGGESTED FIX

------- SortingFocusTraversalPolicy.java -------
*** /tmp/sccs._Da4m2	??L ??+?? 23 11:55:16 2005
--- SortingFocusTraversalPolicy.java	??L ??+?? 23 11:54:02 2005
***************
*** 250,264 ****
              if (log.isLoggable(Level.FINE)) log.fine("### Didn't find component " + aComponent.getName() + " in a cycle " + aContainer.getName());
              return getFirstComponent(aContainer);
  	}
  
  	if (index < 0) {
! 	    // If we're not in the cycle, then binarySearch returns
! 	    // (-(insertion point) - 1). The next element is our insertion
! 	    // point.
  
! 	    index = -index - 2;
  	}
  
  	Component defComp = (Component)defaults.get(new Integer(index));
  	if (defComp != null) {
  	    return defComp;
--- 250,273 ----
              if (log.isLoggable(Level.FINE)) log.fine("### Didn't find component " + aComponent.getName() + " in a cycle " + aContainer.getName());
              return getFirstComponent(aContainer);
  	}
  
  	if (index < 0) {
!             // Fix for 5070991.
!             // A workaround for a transitivity problem caused by ROW_TOLERANCE,
!             // because of that the component may be missed in the binary search.
!             // Try to search it again directly.
!             int i = cycle.indexOf(aComponent);
!             if (i >= 0) {
!                 index = i;
!             } else {
!                 // If we're not in the cycle, then binarySearch returns
!                 // (-(insertion point) - 1). The next element is our insertion
!                 // point.
  
!                 index = -index - 2;
!             }
  	}
  
  	Component defComp = (Component)defaults.get(new Integer(index));
  	if (defComp != null) {
  	    return defComp;
                                     

EVALUATION

The solution may be to try simple search if the component wasn't found. In this case we
would work around the possible transitivity problem.
                                     

EVALUATION

The problem described above breaks the binary search algorithm used in SortingFTP.
When getComponentAfter(..) is called it tries to search the given component in the focus
traversal cycle but due to the transitivity problem the component can't be found. Thus the traversal algorithm gets broken.
                                     

CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mustang


                                     

EVALUATION

I am able to reproduce the problem.  I will look further into this issue.  The work around for those who have to use keyboard to navigate is to use Shift+Tab to traverse focus in reverse direction.  This way you can get to the component after the text field where focus gets stuck.  While this is a rather annoying worka round, the problem is  not critical to be fixed in Tiger.
###@###.### 2004-07-12

This bug really belongs to Java Control Panel. Reassign to java_deployment.
###@###.### 2004-07-26

This is a swing bug.  It is easily reproducible on a smaller test case - attached to this bug report.  If you run the test case with JRE 1.4.2 - focus traverses fine.  If you run it with 1.5.0 - focus gets stuck on text field and can be accessed only if you are going backwards (traversing focus backwards).  This is a regression in accessibility.  One could probably create a test case when focus would get stuck in either direction (just mirror the layout in attached example, and stick more focusable components in the middle).  Re-assigning to swing.  This definitely needs to be fixed in mustang - it is a regression from 1.4.2.
###@###.### 2004-08-04

Very interesting bug. It seems that this bug is dependent on the layout. If I change the GUI layout slightly, the bug is no longer reproducible. I highly suspect that this results from rather large changes made recently by AWT to SortingFocusTraversalPolicy and LayoutFocusTraversalPolicy (4719336).
###@###.### 2004-08-04

The case of the problem is that LayoutComparator is not correct comparator :(
The problem is that it uses ROW_TOPLERANCE and thus the order is not transitive. 
The same problem exists in all releases from 1.4.  This particular tests work fine 
with 1.4 because another bug in traversal policy (which was fixed in tiger :)
###@###.### 2004-08-05

Name: at153223			Date: 09/07/2004

Yes, ROW_TOLERANCE conception used in LayoutComparator really leads to a
transitivity problem. Let's illustrate this on the concrete example, the testcase attached.
There we have a transitive relation formed by three components of 'autoScriptLocationPanel'.
They are (with coordinates) javax.swing.Box.Filler (5,15), 'locationLabel' (30,7) and
'locationTextField' (90,5). The relations are as follows:

Box.Filler is "row-tolerant" to 'locationLabel'
    thus  Box.Filler > 'locationLabel'

'locationLabel' is "row-tolerant" to 'locationTextField'
    thus 'locationLabel' > 'locationTextField'

And so due to transitivity the next statement should be true: Box.Filler > 'locationTextField'.
But this is not the case. For LayoutComparator Box.Filler is not "row-tolerant" to
'locationTextField', and because of this, the relation between these two components is "<".

All this results in that in 'SortingFocusTraversalPolicy.getComponentAfter' when
a component after 'locationTextField' is being searched an incorrect index of the traversal
cycle is calculated.

The difficulty is that this problem caused by "ROW_TOLERANCE conception" is rather a tolerated
error then a bug. We may try to find a workaround. For instance, not including potentially
not focusable (or even not visible) components such that Box.Filler into a traversal cycle
helps. But what problems it may raise and how to detect those not focusable (?)

###@###.###  09/07/2004


======================================================================
                                     

WORK AROUND

Use setNextFocusableComponent(component) to explicitly set the focus.
###@###.### 2004-08-04