JDK-8025001 : setFocusTraversalPolicy() to ContainerOrderFocusTraversalPolicy results in an infinite loop
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7,8,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2010-07-05
  • Updated: 2016-03-15
  • Resolved: 2016-02-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b110Fixed
Related Reports
Relates :  
Description
The attached java program creates a Panel  and adds 2 Buttons to it.

Then it creates a new FocusTraversalPolicy ftp = new ContainerOrderFocusTraversalPolicy() and sets it as the focus traversal policy for the panel using panel.setFocusTraversalPolicy(ftp).

Then it uses FTP's getFirstComponent(), getComponentAfter() to iterate through the panel's children by the order of the focus traversal.

During that cycle we expect to get, first, Button1, then, Button2 because the Javadoc says: 
"From a particular focus cycle root, the policy makes a pre-order traversal of the Component hierarchy, and traverses a Container's children according to the ordering of the array returned by Container.getComponents()."
and because getComponents() returns Button1 and Button2 only. 

However, we see that the loop never terminates constantly returning the Panel itself.

If, however, we do not invoke setFocusTraversalPolicy on the Panel and use the default focus traversal policy that comes with the panel then the loop does terminate returning the Panel itself, Button1 and Button2.
This behavior, however, seems also not in accordance to Javadoc as only Buton1 and Button2  would be expected.

This CR relates to JDK-4959482. However, the explanation given in JDK-4959482 seems not to be sufficient. We did replace JApplet in the initial test by the Panel as was advised in JDK-4959482 and yet we see the same behaviour.


Comments
The criteria for 3rd deferral bulk request bugs: - Not P2 - Not tck-red labeled - Not regression labeled - Not findbugs, parfait, eht, fuzzing labeled -------------------------------------------------------------------- We reviewed these today. We're OK with deferring them. I assume these are for deferral to JDK 9. Please update these so the label says 8-defer-approved and then set FixVersion to 9. Thanks! Kind regards, Mathias
27-09-2013

jdk8: SQE OK to defer but please consider fixing it in 8-pool
26-09-2013

Looks like the components returned by the enumeration algorithm are correct one and the only problem is that instead of stopping on the last component it loops to the first one. Which is an issue, but not a huge one. Considering the fact that this issue been here for a long time and we haven't heard customer complains about it, I think we can safely postpone it until JDK 8.
20-09-2013

pending evaluation
19-09-2013

Moved to the JDK project as we believe there're no errors with the test and it is a JDK issue. Modified the description and added a simple Java program demonstrating the issue.
18-09-2013