JDK-6555704 : Extra focus gain & focus lost event is triggered in win xp.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-05-10
  • Updated: 2007-05-15
  • Resolved: 2007-05-15
Related Reports
Duplicate :  
JDK-6462093 - FocusEvent processed twice when requestFocus after JOptionPane.showMessage()
Relates :  
JDK-6212464 - Undesired JOptionPane loop in FocusLost event
Description
I have a frame, which contains a button & a textfild. Clicking on the button I am displaying a JOptionPane. Once the JOptionPane gets closed the focus should be in text field. I am requesting the focus on the textfield after JOptionPane.showMessageDialog().  I have added focus listeners to Button & textfield on the frame. In focusLost method i am getting the opposite component of the component which lost the focus.

Step to reproduce
------------------
1) Run the attached program.
2) Click on the Button. You will see a JOptionPane. The opposite component of the button on the frame is JOptionPane "OK" button. Oberve on the console that "button focus gained " & "button focus lost" message is displayed. And opposite component of button on the frame is "OK" button of Joptionpane.
3) Click on the "OK" button of JOptionPane. The JOptionPanen gets close.  Observe on the console that textfield(tf) gains the focus & lose the focus. its opposite component is null. This is incorrect textfield is not suppose to gain the focus. 
but the focus goes to "Button & loses the focus And later goes to textfield. , which is the correct behaviour.

This works fine in  solaris , but fails in  window xp. I tested this in jdk6.0 & jdk7.0.
Comments
EVALUATION Well, it looks like we can not filter out the request in shouldNativelyFocusHeavyweight() because the situation is the same as for request we do in DKFM on WINDOW_GAINED_FOCUS (or we need to add one more majic flag for this). Another approach would be to not request focus in DKFM is there are pending requests, but this way we will not restore focus to the compoment which temporary lost focus (so this will looks trange, though there is no such statements in the Focus spec). So, both approaches have some disadvantages and the problem is not a spec violation thus I'm postponing the fix for now (hope will find a better way to fix or more reasons to fix it :)
15-05-2007
EVALUATION I was able to reproduce the problem described in the first comment (additional focus gain/lost on text field just after closing dialog) on Windows. I think I knwo the cause of the problem: the test requests focus on tezt field just after closing dialog. This request is processsed by our focus subsystem and finally delivered to KFM.shouldNativelyFocusHeavyweight(). At this point native focus owner is null, native focused window is the frame, and there are no pending focus requests. In this case we thinks that we should natively set focus and so this produces problematic focus events. Imho in this case we should do nothing and wait when DKFM will process WINDOW_GAINED_FOCUS on the frame and request focus for text field as a most recent focus owner (note: most recent focus owner has been already updated in requestFocus()). The only question is if it is possible to have similar situation (naive focuse owner == null and native focused window != null) not during the activation process. (need to think about this)
14-05-2007
EVALUATION I've rechecked behavior on linux and everything works fine. Doublechecked with ###@###.###, and he confirmed that the comment about linux was added by mistake. So. there is no problems on linux/solaris. (will check windows soon)
14-05-2007
EVALUATION the test calls requestFocus() on rhe text field just aftre option pane is closed and so I'd expect that the button will receive focus first, then focus will be transfered to the text field (we need to restore focus to button because it received temrporary focus lost which means the component should receive focus back shortly). Need to check why we have different order of focus events.
14-05-2007
EVALUATION With 6.0-fcs and the latest (~b12) 7.0 build I observe the different behavior on Windows and Linux, and both are wrong: On Linux: focusGained for button, option pane is opened, focusLost for button, option pane is closed, focusGained for text field. On Windows: focusGained for button, option pane is opened, focusLost for button, option pane is closed, focusGained for text field, focusLost for text field, focusGained for button, focusLost for button, focusGained for text field.
11-05-2007