United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6566905 getFocusOwner() return Invisible component as focusowner
JDK-6566905 : getFocusOwner() return Invisible component as focusowner

Details
Type:
Bug
Submit Date:
2007-06-07
Status:
Closed
Updated Date:
2011-05-18
Project Name:
JDK
Resolved Date:
2011-05-18
Component:
client-libs
OS:
solaris_10
Sub-Component:
java.awt
CPU:
sparc
Priority:
P4
Resolution:
Fixed
Affected Versions:
6
Fixed Versions:

Related Reports
Relates:

Sub Tasks

Description
I have a frame on which i have added some awt components. I have set one button to setFocusable(false), When i click the setFocusable(false)button the components on the frame gets removed one by one except setFocusable(false) button & a list & then later i am checking for the focus owner & focus window. 
On windows it gives Button1(first component) & next time when click the button i am getting frame as the focusowner & focus window. But on solaris , i am getting Button1 as the focus owner & next time when i click i am getting choice as the focus owner( second component ) & frame as focus window.  Where choice is removed. So the removed component can't be a focus owner. 

I tried an another scenario(Scenario #2) instead of removing all the components(see comment in actionperformed() ) , i just removed first two components & left last two components one focusable(list) & one nonfocusable component(button). But Still the problem can be seen. i,e i expect focus to be on list , but i can see the above described results.

I tried with an another scenario(Scenario #3), When the frame is visible , press tab so that second component may receieve the focus & when i press the nonfocusable button. the list receives the focus as expected.

Step to reproduce for Scenario1:
--------------------------------
1) Run the attached program.
2) Click on "Button2". Observe that components gets removed & see the console that "choice is the focus owner & its opposite component is "button1". If you see the same then the bug is reproduced.

Step to reproduce for Scenario2:
--------------------------------
Note:- Comment the line in actionPerformed line ( i have given the comment in the testcase).
1) Run the attached program.
2) Click on "Button2" . Observe that List dn't have focus. If you see the same then the bug is reproduced.

Step to reproduce for Scenario 3:
--------------------------------
Note:- Comment the line in actionPerformed line ( i have given the comment in the testcase).
1) Run the attached program.
2) Press "Tab" .  Now choice gain the focus.
2) Click on "Button2" . Observe that List have focus.  This is the correct behaviour.

I tested this in jdk1.5.0  to jdk 1.7.0.

                                    

Comments
EVALUATION

well, this is a known problem of our focus code, it allows non-visible componentn become
a focus owner (if it was visible when requestFocus() was called).  This is because the
only place where we check visibility of possible focus owner is requestFocus()

I think we have a number of bugs cause dby the same problem.
                                     
2007-06-07
EVALUATION

the test itself also contain a problem.  it checks current focus owner just after it was
removed.  But focus transfer is asynchonous thus you need to wait for events to check
focus state.  E.g. user can register property change listener on current 
keyboard focus manager.
                                     
2007-06-07
EVALUATION

Event after correcting the test we still may have the same problem and it has been fixed
by the fix for 4726458.
                                     
2007-06-25
SUGGESTED FIX

see 4726458
                                     
2007-06-25



Hardware and Software, Engineered to Work Together