JDK-5095117 : [Cinnabar17] On X86, suntea login page can't be input
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: solaris_10,cinnabar,5.0
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: linux_suse_slec,solaris,solaris_10
  • CPU: unknown,x86
  • Submitted: 2004-09-01
  • Updated: 2005-05-26
  • Resolved: 2005-05-26
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 JDK 6
5.0u3 b07Fixed 5.0u4Fixed 6Fixed
Related Reports
Duplicate :  
JDK-5098355 - [Cinnabar16 & 17 linux] Textfield can not select,input or delete
Duplicate :  
JDK-6264596 - [JDS3LIN] keyboard does not work on vino remote desktop from nevada
Duplicate :  
JDK-6271601 - Solaris 10 sparc Mozilla v1.7 - Can't input data into Suntea
Relates :  
JDK-6421652 - Problem run java applet apps with JRE 1.5.0_01, JRE 1.5.0_07 in Solaris 10 environment
Relates :  
JDK-6211626 - [cinnabar25 Linux]Can not input amount into Amount field in SunTea
Description
Reproduce Steps:
1 On Cinnabar17 for X86, Solaris10-66, jdk1.5.0-beta3-b62, mozilla1.7(2004/08/24)
2 Launching http://suntea.central.sun.com. There is a window pops up. But at first time it can't be input untill you switch to another window then come back to suntea.
Comments
SUGGESTED FIX ------- awt_TopLevel.c ------- *** /tmp/sccs.EEaaNW Wed Oct 13 18:30:58 2004 --- awt_TopLevel.c Wed Oct 13 18:19:51 2004 *************** *** 1272,1282 **** if ( oppositeShell != NULL && isFocusableWindowByShell(env, oppositeShell) && isFocusableWindowByShell(env, w) || (oppositeShell == NULL)) { ! awt_canvas_setFocusedWindowPeer(NULL); JNU_CallMethodByName(env, NULL, this, "handleWindowFocusOut", "(Ljava/awt/Window;)V", oppositeWindow); if ((*env)->ExceptionCheck(env) == JNI_TRUE) { (*env)->ExceptionDescribe(env); (*env)->ExceptionClear(env); --- 1272,1293 ---- if ( oppositeShell != NULL && isFocusableWindowByShell(env, oppositeShell) && isFocusableWindowByShell(env, w) || (oppositeShell == NULL)) { ! /* ! * Fix for 5095117. ! * Check if current native focused window is the same as source. ! * Sometimes it is not - we must not however clean reference to ! * actual native focused window. ! */ ! jobject currentFocusedWindow = awt_canvas_getFocusedWindowPeer(); ! if ((*env)->IsSameObject(env, this, currentFocusedWindow)) { ! awt_canvas_setFocusedWindowPeer(NULL); ! } ! (*env)->DeleteLocalRef(env, currentFocusedWindow); ! JNU_CallMethodByName(env, NULL, this, "handleWindowFocusOut", "(Ljava/awt/Window;)V", oppositeWindow); if ((*env)->ExceptionCheck(env) == JNI_TRUE) { (*env)->ExceptionDescribe(env); (*env)->ExceptionClear(env); ###@###.### 2005-06-07 15:10:16 GMT
07-06-2005
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: dragon mustang
22-09-2004
EVALUATION This bug may be better addressed by AWT. Will reassign. ###@###.### 2004-09-08 Just FYI, I was not able to reproduce this bug on my Cinnabar b17 (x86) machine with java-b62 on Mozilla 1.7. ###@###.### 2004-09-10 I just test it on Cinnabar18(x86), it still can reproduce. The tips: make sure the login window is first pops up and does not be overlapped by another window. ###@###.### 2004-09-14 I am unable to run SunTEA through VPN, and I don't have access to SWAN. However, with the kind help of ###@###.###, I was able to get the logs of focus events when bug reproduces. I see the following(comments start with "***"): Sep 16, 2004 11:24:54 AM java.awt.KeyboardFocusManager retargetFocusEvent FINE: >>> java.awt.event.WindowEvent[WINDOW_GAINED_FOCUS,opposite=null,oldState=0,newState=0] on frame1 *** frame1 is SunTEA main window, it gets focus Sep 16, 2004 11:24:54 AM java.awt.KeyboardFocusManager setGlobalActiveWindow FINER: Setting global active window to COM.sun.ir.suntea.client.SunteaApplication[frame1,112,84,800x600,layout=java.awt.BorderLayout,title=SunTEA 3.55 -- SUN PROPRIETARY/C ONFIDENTIAL,resizable,normal], old active null *** It becomes current active window Sep 16, 2004 11:24:54 AM java.awt.DefaultKeyboardFocusManager dispatchEvent FINER: tempLost null, toFocus java.awt.TextField[textfield0,145,0,100x32,text=,editable,selection=0-0] *** textfield0, login field, is the focus candidate Sep 16, 2004 11:24:54 AM sun.awt.motif.MComponentPeer requestFocus FINER: Current native focused window null Sep 16, 2004 11:24:54 AM sun.awt.motif.MComponentPeer requestFocus FINER: Parent window COM.sun.ir.suntea.client.SunteaApplication[frame1,112,84,800x600,layout=java.awt.BorderLayout,title=SunTEA 3.55 -- SUN PROPRIETARY/CONFIDENTIAL,resiza ble,normal] Sep 16, 2004 11:24:54 AM sun.awt.motif.MComponentPeer requestFocus FINER: Requested window focus: false Sep 16, 2004 11:24:54 AM sun.awt.motif.MComponentPeer requestFocus FINER: Waiting for asynchronous processing of window focus request Sep 16, 2004 11:24:54 AM java.awt.Component requestFocusHelper FINEST: FAIL 4 *** Request on textfield1 fails because frame1 is not current NATIVE focused window. In our code, there is only one place where native focused window is changed - in awt_TopLevel.c, shellEH function. We do so in response to two focus event - set it to NULL on FocusOut, set it to the source window on FocusIn. On FocusIn we also generate WINDOW_GAINED_FOCUS for the source window. Since frame1 received WGF, it must be current native focused window. However, since it is not, I assume some another window received FocusOut and cleaned the value of native focused window. I don't have the ability to log the native code actions, however I can assume that that additional FocusOut message is a wrong, synthetic message send to us. It might be Mozilla or XEmbed, the latter is most likely. So this seems to be a race - since someone sends to us FocusOut it assumes that his window is active right now, but it is not. To workaround this behavior we can check for current focused window and do not clear it if it is different from the source of event ###@###.### 2004-09-16 With JRE with the proposed workaround, the bug is not reproducible. The bug is also not reproducible with XToolkit. ###@###.### 2004-09-20 Should fix this in next (update) release ###@###.### 2004-09-20 There was an idea to fix the root of the problem and the root was assumed to be that FocusOut event sent by XEmbed. But it seemed to be risky not to propagate a paired (for FocusIn) event to a widget. Thus it's better not to breake consistency but just to take the workaround proposed above (by ###@###.###) as a fix. ###@###.### 10/13/04 14:08 GMT ###@###.### 2005-2-07 13:24:29 GMT
22-09-2004
WORK AROUND Switch to another window then come back to suntea ###@###.### 2004-09-20
20-09-2004