JDK-4878303 : Can't input character into the applet text field when doing the applet demo
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4mercury,1.4mercury_02
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2003-06-13
  • Updated: 2004-11-10
  • Resolved: 2004-11-10
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
1.4.2_01 01Fixed
Related Reports
Relates :  
JDK-5035314 - REGRESSION: TextField becomes uneditable after browser window is minimized
Relates :  
JDK-4937891 - Can't input or delete characters into textfield of applet demo
Description
<1> Steps to reproduce:
1.Launch the Mozilla1.4(GTK1.2 Build) for Mercury with jre1.4.2_b19 on SuEC_RC1 and Gnome2.0.
2.Open 
http://baseman.prc/jdk-applet-demo/1.4.2/demos/applets/ArcTest/example1.html
3.Put the cursor's focus into text field then can't type anything to it.

<2> steps to reproduce:
For reproduce this kind of input focus bugs :
1.Open Animator ex1 or others in http://baseman.prc/jdk-applet-demo/1-4-2.htm,when the applet is running, press shift and click, then the pop up a window displays some information,click Cancel button.
2. Run the ArcTest or other applets as Comments attach, or bug :
4878296,4878307,all of these applets can't input anythings in the text fields.
    
This bug can reproduce with jre1.4.2_b26. This bug also can reproduce on solaris with jre1.4.2_b27 using mozilla 1.2.1(GTK1.2 BUILD).

###@###.### 2003-06-16

<3>Steps to reproduce:
In mozilla built by gtk1.2,if an applet pop up a new window, then run another applet that include a java edit box, the bug also happen. Following is detail
example.

1. Go to http://suntea.singapore.sun.com, whent it pop up java applet login window ,input Employee number or password, and quit.
2. Run an applet such as j2sdk1.4.2's demo, Arc Test(1.1) or other applets with edit box.
3. Move the focus into the edit box(Text field or area) ,and type some characters.
4.Can't input,the focus lost.

###@###.### 2003-06-25
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_01 tiger FIXED IN: 1.4.2_01 tiger INTEGRATED IN: 1.4.2_01 tiger tiger-b13 VERIFIED IN: 1.4.2_01 tiger
24-08-2004
SUGGESTED FIX Name: dmR10075 Date: 06/27/2003 (diffs below are incomplete because of unresolved externals and provided only to demonstrate the fix for the problem. for complete diffs, see attached webrev) Generate synthetic FocusIn for embedded frame and dispatch it when embedded frame becomes visible. *** /home/dom/bugs/4878303/src/solaris/classes/sun/awt/motif/MEmbeddedFramePeer.java- Fri Jun 27 17:11:10 2003 --- /home/dom/bugs/4878303/src/solaris/classes/sun/awt/motif/MEmbeddedFramePeer.java Fri Jun 27 17:11:10 2003 *************** *** 20,23 **** --- 20,33 ---- } native void NEFcreate(MComponentPeer parent, long handle); native void pShow(); + + public void setVisible(boolean vis) { + super.setVisible(vis); + if (vis) { + // Fix for 4878303 - generate WINDOW_GAINED_FOCUS and update if we were focused + // since noone will do it for us(WM does it for regular top-levels) + synthesizeFocusIn(); + } + } + native void synthesizeFocusIn(); } *** /home/dom/bugs/4878303/src/solaris/native/sun/awt/awt_TopLevel.c- Fri Jun 27 17:11:12 2003 --- /home/dom/bugs/4878303/src/solaris/native/sun/awt/awt_TopLevel.c Fri Jun 27 17:11:11 2003 *************** *** 62,67 **** --- 62,68 ---- #include "awt_util.h" #include "img_util.h" #include "awt_wm.h" + #include "awt_util.h" #ifdef __linux__ void adjustStatusWindow(Widget shell); *************** *** 78,83 **** --- 79,85 ---- jint x, jint y, jint w, jint h, Boolean setXY); Widget findTopLevelByShell(Widget widget); + extern EmbeddedFrame *theEmbeddedFrameList; extern struct ComponentIDs componentIDs; extern struct MMenuBarPeerIDs mMenuBarPeerIDs; extern struct MComponentPeerIDs mComponentPeerIDs; *************** *** 4115,4120 **** --- 4117,4148 ---- (*env)->SetObjectField(env, self, fid, lpeer); } + + JNIEXPORT void JNICALL + Java_sun_awt_motif_MEmbeddedFramePeer_synthesizeFocusIn(JNIEnv *env, jobject this) { + EmbeddedFrame *ef; + Boolean dummy; + + AWT_LOCK(); + ef = theEmbeddedFrameList; + while (ef != NULL) { + if ((*env)->IsSameObject(env, ef->javaRef, this)) { + XFocusChangeEvent xev; + xev.display = awt_display; + xev.serial = 0; + xev.type = FocusIn; + xev.send_event = False; + xev.window = XtWindow(ef->embeddedFrame); + xev.mode = NotifyNormal; + xev.detail = NotifyNonlinear; + shellEH(ef->embeddedFrame, this, (XEvent*)&xev, &dummy); + break; + } + ef = ef->next; + } + AWT_UNLOCK(); + } + JNIEXPORT void JNICALL Java_sun_awt_motif_MEmbeddedFramePeer_NEFcreate(JNIEnv *env, jobject this, jobject parent, jlong handle) ###@###.### 2003-06-27 ======================================================================
27-06-2003
EVALUATION This should be awt 's regression bug, it can only be reproduced on mozilla gtk1.2 build, can't be reproduced on mozilla gtk2.0 build. ###@###.### 2003-06-16 Sounds similar to other bugs reported when using Mozilla. Hopefully this can be resolved by the XEmbed work. ###@###.### 2003-06-17 Name: dmR10075 Date: 06/25/2003 I verified that XEmbed(Mozilla from Robin, XAWT/XEmbed) fixes it. ###@###.### 2003-06-25 ====================================================================== Name: dmR10075 Date: 06/26/2003 As far as I understood so far, the bug can be reproduced with the following sequence: - start applet, see comments for TestFocus.java/html - click on it, another frame will appear - click on button in another frame, it will be hidden - reload applet - can't give focus to applet. ###@###.### 2003-06-26 ====================================================================== Name: dmR10075 Date: 06/27/2003 When the problem happens, focus stops working. In normal situation, when I move mouse into applet, textfield draws focus rectangle indicating it is focused and it really is - on Java level it is focus owner. When the problem happens, as I see from debug output and server logs, the native focus and java focus are set correctly - browser's top-level has native focus and Java textfield is focus owner. But when I move mouse into the applet nothing happens. I didn't find the difference in focus states or sequence of events between two cases so far. ###@###.### 2003-06-27 ====================================================================== Name: dmR10075 Date: 06/27/2003 I noticed that when some applet is being loaded it doesn't receive native FocusIn(targeted to browser) which we use to detect focus state of browser and active state of applet. After adding the sending of such event on EmbeddedFramePeer.setVisible(true) the problem disappeared. ###@###.### 2003-06-27 ======================================================================
27-06-2003
WORK AROUND If lost input focus on edit box, open a new window in mozilla such as composer,java console or view page source that can make the focus go back again. ###@###.### 2003-06-25
25-06-2003