JDK-4767070 : Loosing Focus upon clicking button in pop up window.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.1,1.4.1_01
  • Priority: P1
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux,solaris_8
  • CPU: x86,sparc
  • Submitted: 2002-10-23
  • Updated: 2003-01-31
  • Resolved: 2002-11-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.
Other Other
1.4.1_02 02Fixed 1.4.2Fixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Description
We have a JApplet with JPanel having JTabbedPanes. Within these JTabbedPane we have JTextField and JButton. Upon entering no data into the JTextField and
thereafter clicking the JButton, we are validating the data in the JTextField and showing the ERROR message using JOptionPane (a pop up window). If user clicks on "OK" option we loose the FOCUS. We even tried using requestFocus() methods to redirect the FOCUS.  However, same code works with versions prior to JDK 1.4 with change in package name to make use of SWING 1.0.3 API.

Please untar the attached FocusBug.tar and follow the instructions in the README file to recreate the bug. 

I have submitted a same bug via external site. The bug review id assigned to that is 165473.  However, we have been asked to submit the bug via internal bugTraq for faster response and the because of the fact that there is no way to provide the sample programs once you submit the bug via external site till we get any response. Please look into it asap.

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.1_02 mantis FIXED IN: 1.4.1_02 mantis INTEGRATED IN: 1.4.1_02 mantis mantis-b08
24-08-2004

WORK AROUND Name: dmR10075 Date: 10/26/2002 - Do not use mouse to close message dialog - If you have problem with focus switch to another application then switch back to Netscape. ======================================================================
24-08-2004

SUGGESTED FIX Name: dmR10075 Date: 10/29/2002 *** /tmp/geta29875 Tue Oct 29 19:51:15 2002 --- awt_util.c Tue Oct 29 19:49:02 2002 *************** *** 1212,1217 **** --- 1212,1218 ---- ef->embeddedFrame = embeddedFrame; ef->frameContainer = win; ef->javaRef = javaRef; + ef->eventSelectedPreviously = False; /* initialize the xt coordinates */ awt_util_updateXtCoordinatesForEmbeddedFrame(embeddedFrame); *************** *** 1236,1256 **** } else { XGetWindowAttributes(awt_display, ef->frameContainer, &win_attributes); ! if (win_attributes.your_event_mask & StructureNotifyMask) { ! /* ! * someone already select StructureNotify for this window ! * this should not normally happen. ! * if this is the case, we assume that the event will ! * remain selected all the time so we dont need to touch ! * the event mask ! */ ! ef->eventSelectedPreviously = True; ! } else { ! DTRACE_PRINTLN("add event to frame"); ! ef->eventSelectedPreviously = False; ! XSelectInput(awt_display, ef->frameContainer, ! win_attributes.your_event_mask | FocusChangeMask); ! } } /* ef will become the head of the embedded frame list */ --- 1237,1244 ---- } else { XGetWindowAttributes(awt_display, ef->frameContainer, &win_attributes); ! XSelectInput(awt_display, ef->frameContainer, ! win_attributes.your_event_mask | FocusChangeMask); } /* ef will become the head of the embedded frame list */ ======================================================================
24-08-2004

EVALUATION You can get Netscape 7 at: /usr/dist/share/netscape,v7.0/netscape Use file:///usr/dist/share/netscape,v7.0/java/ControlPanel.html to point it at a different JRE. This still happens with mantis build 3. When you click on the option pane close button Component.nextFocusHelper is eventually invoked but at this point there is no valid focus cycle root ancestor and nextFocusHelper fails, thereby causing focus to be lost. A subsequent click on a text field in the applet appears to fail at the peer level, eg requestFocusHelper in Component appears to be failing because: peer.requestFocus(this, temporary, focusedWindowChangeAllowed, time); is returning false. Where peer is an MPanelPeer. As this appears to be in the awt side, I am reassigning. ###@###.### 2002-10-24 Name: dmR10075 Date: 10/26/2002 I found: - if showMessageDialog is created with parent as visible Frame then everything works well. In all other situations it fails. - when it fails we receive non-synthetic FocusIn on dialog with mode=0, detail=5. It is not our fault that we treat this event as WINDOW_GAINED_FOCUS as it actually is. I don't know/understand why server sends it to us. I have a guess that this happens because our dialog have no parent top-level to whom focus can be "reverted to" in terms as XSetInputFocus defines revert_to parameter. Though it is not the reason to send us bogus FocusIn. ###@###.### 2002-10-25 ====================================================================== Name: dmR10075 Date: 10/26/2002 Oleg Sukhodolsky have performed initial evaluation of the problem and provided me with the following information: - The bug is not 100% reproducible, and it is not reproducible at all in some configurations(e.g. Gnome/Sawfish). It means it is a thread race. - The bug is 100% NOT reproducible if you use keyboard to close dialog not mouse. This is a workaround. - After bug has been reproduced normal behavior can be returned by clicking on another window, then returning back to Netscape. This is another workaround. - After dialog has been closed it receives WINDOW_ACTIVATED event thus causing a mess in Java internal focus state which prevents user from focusing components in applet by mouse. ###@###.### 2002-10-25 ====================================================================== Name: dmR10075 Date: 10/29/2002 I found the cause of the problem: in awt_util.c there is a code(in addEmbeddedFrame) which is doing the right thing - it adds FocusChangeMask on parent of embedded frame so we know when plugin receives focus. However, we don't receive any focus events when plugin recieves focus - and that was the cause of the problem. This happens because this code isn't executed anymore (starting from some time) because it is guarded by condition which is always False. After I made this code to be executed unconditionally problems dissappeared - both the problem described in this report and another problem - that plugin didn't receive focus back when you switch from browser/back to it using titlebar. See suggested fix for diffs. ###@###.### 2002-10-29 ======================================================================
29-10-2002